Need C# programmers with socket / TCP interest

[Chad Z. Hower aka Kudzu]

It's not just a T though, of course. It's a TId, an Id, an EId, a
TEvent etc. It certainly doesn't *break* a library, but when mixed with

TEvent is a Borland type - not sure much can be done about that. But they
map to .Net events and you really should not be interacting with them that
I know of. There are a LOT of internals that the end user will never see.

the .NET conventions, it makes for far less readable code, IMO. Don't
forget that you're rather used to the conventions - I'm thinking about
people whose *only* exposure to the Delphi conventions is Indy.

But users are not programming in their own code using these conventions.
Whether its TIdHTTP, or IndyWebClient, its just a class name that Ive
gotten from docs an am implementing.

#2 is solved. #1 I am the most open about changing - but I really need to
be sure that it is necessary.

#3 - Im not so sure about. Open but needs a lot more convincing.

Not if they're in my team they don't

Correctr me if Im wrong, but in MFC C was the standard. CHTTP would be the
class name etc.

Mixing conventions is just a really bad idea, IMO - for one thing the
conventions are a subliminal hints about which language you're using,
so you don't get confused in terms of the idioms to use etc.

..Net is not a language though. C# is, VB is. Developers use their own
conventions in their own code.

MS might name someting BoogerClass. I might call it MucousClass because of
whatever reason - but thats a convention too.

Excellent. That's a big step forward.

Yes. This was going to be a big issue and we knew this.

Unfortunately the other types are still public. Typing "b" then ctrl-
space in VS.NET is still going to suggest "Borland", and in the classes
where the developer has a "using Borland.Vcl.Classes" directive to make
working with TStrings easier, typing "t" then ctrl-space is going to
suggest loads of extra classes.

Nope - You as an end user wont need to use TStrings. See the code I posted.
You COULD use it if you want, but my bet is most .net developers will want
to stick to what they are familiar with. In this case string arrays.

That's good. I hadn't seen that in the article.

Please take a quick gander - its not very long:

I'm sure Indy is big, but IL is generally pretty small For the sake
of interest, I'll look into this and come back with the results.

We have dynamnic linked versions, ie Borland stuff in its own packges. I
just recopmiled the dynamic one, its 1.5 MB. Thats JUST Indy. No Borland
parts.

We will be reducing our dependency on some Borland parts, but I dont
suspect it will reduce it a lot unless we do a LOT of ifdeffing in some
units which might be possible if necessary. We only use RTL, not the VCL
parts. And of the RTL, only a limited number of classes, but quite a bit of
RTL system type routines.

Then they should be encouraged to, IMO. If a developer doesn't update
the docs, how is anyone else supposed to? Isn't it just as quick to
write a short note in the docs as to what's changed as it is to write
the same note to someone in the docs team so that they can do it at a
later date?

Its horrible docs. Our doc team diffs and makes changes as necessary.
Besides that, programmers rarely doc, and in open source you cannot MAKE
anyone do anything.

Code folding takes care of this where it's an issue, I find. Indeed,
unless I'm editing a method, I find it's often a good idea to *only*
have the method comment up rather than the method body. If the method
comment doesn't cover everything you need to know, then the comment
should be fixed.

Code folding is new for both Delphi and MS and did not exist before. Indy
is almost 10 years old!

As I said before, I'm sure they aren't a problem at all for you, as
you're already familiar with the convention, but I'm speaking for
myself - and I they lead to a significant reduction in readability as
far as I'm concerned.

TIdHTTP vs HTTP? Yes a different, but think of it as a libarary prefix.
What if it was IndyHTTP? I doubt anyone would complmain then, but it would
be the same exact issue.

If you ever do decide you'd like to seriously consider something to
convert the naming conventions and possibly Delphi type replacement

The types - maybe. We can handle that I think as part of the build process
pretty easily.

The type adaptors - Im less convinced about. Its a hard change, or at least
a lot of ifdefs.

(without your Delphi code having to change), let me know and I'll look
into it. I've looked into the PE and IL file formats a bit, and
wouldn't mind revisiting that work and trying to write a tool which let
you really manipulate assemblies in the kind of ways I've been talking
about. It wouldn't be a small task, but it would have uses way beyond
Indy.

What would this tool do? We can modify source before it goes in as part of
the build process. The adaptor issue would require code changes, something
I doubt your tool could do.

You didnt respond much to #3 after I posted the code. Did you look at it?
Its pretty much pure .net - is that really much of an issue with such easy
adapators?




--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Jon Skeet [C# MVP]]

With C++ in MFC at least classes were C+Classname. C++ does allow managed
code. Assuming that somone has "ported" existing code and its single source -
have they removed all their C's from the code?

They should have done, IMO, yes - especially if they care about
consistency with other .NET libraries.

 

[Chad Z. Hower aka Kudzu]

maybe the functions could be overloaded, so they accept the standard .NET
classes
( ifdef-ed for the dotnet build)

Thats exactly what I was thinking. But imagine all the places it would have
to go.....

I cannot think of any way to write a tool to perform this work automatically
either.

Actually... Hmm we could hit two birds with one stone.

We could

TIdHTTP
+--HTTP (Dot net version)

that adds the new methods. This would fix naming, as well as add the methods
without violating our IFDEF principle.

The problem is all the middle classes though like TCPConnection etc, and
TIdHTTP would still be visible.. hmm bad idea..


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Chad Z. Hower aka Kudzu]

Well, it doesn't take *quite* that much monkeying. I would use:

Thats still quite a bit for such a small operation, espe when compared to
Delphi.

My point wasnt so much that its a lot, that with all this "chaff" will
users really care about:

new TIdCLRStream(ms)

vs

ms
?

However, a nicer interface (IMO) would be for LHTTP.Get to take a
TextWriter as a parameter instead, if it's fundamentally going to be

We can make more adaptors VERY easily. This is a easier way than creating
many method forms. I dont mind adding adaptors at all.

writing character data. Alternatively, I'd have LHTTP.Get *return* a
stream, or TextReader, or string, rather than take one and write into
it. Maybe the "passing in a stream" way of doing things is common in
Delphi - it's not in .NET.

There is one that returns a string actually already. I was just showing how
to use an adaptor in this example.

I think it can be "post build" as it were - it needn't do anything to
source files, certainly.

But which is easier? Pre build we can do with a slightly advanced search
and replace added into our build too. And we already have have one because
of Indy being in otehr product and needing to be realiased to "Renamspace"
it. It currently only does the unit names, but could do classes without too
much trouble.

I'm pretty sure I could work out something to get rid of them though,

How without inheriting new classes and having to maintain all those
variants?

and even if you don't want to do that, I hope you wouldn't mind me
using Indy in a modified form

Not at all - in fact:

1) I couldnt stop you. The Indy license permits this and much more.

2) If you or a VS team wants to maintain all these variants or additions,
problem is solved!

Thats what I was trying to express in my first message. We are looking for
VS people to work WITH.

Obviously I don't want to do anything that would adversely affect your
existing user base - I'm just interested in how much effort you're
willing to put into making it *really* inviting for "just .NET" users -

A fair bit. My company is doing a lot of .net and so are many of the Delphi
people, but most of them are using Delphi for .net.

and in my view, the crux of that is the naming convention issue, which
again I think I can solve, albeit with a lot of work, but in a fairly
future-proof way.

The naming convention is quite solvable. Its issue #3 that is a real
sticker IMO.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Chad Z. Hower aka Kudzu]

They should have done, IMO, yes - especially if they care about
consistency with other .NET libraries.

But lets assume they are single source, and still have to support native MFC.
ie, its one source code base.

Would people hold the same standard as they would to Delphi or say "Well its
MS code, its ok".


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Jon Skeet [C# MVP]]

TEvent is a Borland type - not sure much can be done about that.

I meant prefixes to other names. For instance, there's the
TEventNewNewsList type.

But they map to .Net events and you really should not be interacting with
them that I know of. There are a LOT of internals that the end user will
never see.

Sure - but I get presented with them every time I use intellisense to
try to find the class I'm actually after...

But users are not programming in their own code using these conventions.
Whether its TIdHTTP, or IndyWebClient, its just a class name that Ive
gotten from docs an am implementing.

But TIdHTTP is much less readable to me than IndyWebClient.

Correctr me if Im wrong, but in MFC C was the standard. CHTTP would be the
class name etc.

Absolutely. And in MFC I'd insist on that. However, I was saying that
if they're in my team writing C#, they won't do that. Using the
recommended conventions for the language you're using is the One True
Way, IMO.

.Net is not a language though. C# is, VB is. Developers use their own
conventions in their own code.

..NET has a set of conventions though - and C# shares them.

Nope - You as an end user wont need to use TStrings. See the code I posted.
You COULD use it if you want, but my bet is most .net developers will want
to stick to what they are familiar with. In this case string arrays.
Righto.


Please take a quick gander - its not very long:
<http://www.atozed.com/indy/Texts/VSIntro.iwp>

Hmm... it seems that I can get away from using TStrings, but only by
using TIdStringArray. It's still the same problem: there's a perfectly
good way of representing a string array in .NET, namely String[]. The
original complaint is having to learn classes which are effectively
unrelated to the network protocol I'm trying to use.

We have dynamnic linked versions, ie Borland stuff in its own packges. I
just recopmiled the dynamic one, its 1.5 MB. Thats JUST Indy. No Borland
parts.

Right. Only just over half the size is interesting... Thanks for saving
me the effort though

We will be reducing our dependency on some Borland parts, but I dont
suspect it will reduce it a lot unless we do a LOT of ifdeffing in some
units which might be possible if necessary. We only use RTL, not the VCL
parts. And of the RTL, only a limited number of classes, but quite a bit of
RTL system type routines.
Right.


Its horrible docs. Our doc team diffs and makes changes as necessary.

Uurgh! That sounds completely the wrong way round to me. I believe in
writing docs before code - otherwise you're writing up the
implementation rather than the interface, effectively.

Besides that, programmers rarely doc, and in open source you cannot MAKE
anyone do anything.

Your programmers may rarely doc, but that's not been my experience in
other open source projects. The documentation quality does vary
considerably, but various projects manage perfectly well with the
developer docs in the source.

Code folding is new for both Delphi and MS and did not exist before. Indy
is almost 10 years old!

Sure - but that doesn't mean it's a valid objection *now*.

TIdHTTP vs HTTP? Yes a different, but think of it as a libarary prefix.
What if it was IndyHTTP? I doubt anyone would complmain then, but it would
be the same exact issue.

No it wouldn't - because "Indy" is much easier to read than "TId". Once
again, I don't believe you're able to really see the point from my
perspective, because you're so used to TId as a prefix.

The types - maybe. We can handle that I think as part of the build process
pretty easily.

The type adaptors - Im less convinced about. Its a hard change, or at least
a lot of ifdefs.

No need - so long as you've got a decent tool

What would this tool do? We can modify source before it goes in as part of
the build process. The adaptor issue would require code changes, something
I doubt your tool could do.

Why do you doubt it? IL isn't that complicated. I'd make the tool
modify the method body to do the conversions at the start/end of the
methods, as required, and change the method signature appropriately.

You didnt respond much to #3 after I posted the code. Did you look at it?
Its pretty much pure .net - is that really much of an issue with such easy
adapators?

It's just another straw potentially breaking the camel's back. On its
own it's not critical, but I still don't like the idea of having to
learn *anything* about extra types for which a perfectly good .NET
equivalent already exists.

 

[Chad Z. Hower aka Kudzu]

I meant prefixes to other names. For instance, there's the
TEventNewNewsList type.

You mean TIdEvent?

Those would all be redone as part of the renaming. We are working on a
rename utilitly now as it looks like we iwll need it for something else
too.

Sure - but I get presented with them every time I use intellisense to
try to find the class I'm actually after...

The Indy ones you mean? TIdEventXXX?

But TIdHTTP is much less readable to me than IndyWebClient.

Or is it because its "not delphi"? That is how much user "revulsion" is
preference and how much is Delphi "T"?

Absolutely. And in MFC I'd insist on that. However, I was saying that
if they're in my team writing C#, they won't do that. Using the

Yes, that I understood.

recommended conventions for the language you're using is the One True
Way, IMO.

But what if was C++ and single source between Native and .Net?

Please take a quick gander - its not very long:
<http://www.atozed.com/indy/Texts/VSIntro.iwp>

Hmm... it seems that I can get away from using TStrings, but only by
using TIdStringArray. It's still the same problem: there's a perfectly
good way of representing a string array in .NET, namely String[]. The
original complaint is having to learn classes which are effectively
unrelated to the network protocol I'm trying to use.

I think you missed the point again..... You dont use TidStringArray. Its a
"dummy" class. It works just like TIdCLRStream.

You use strings[], just when you call Indy that needs a TStrings you pass

new TIdStringArray(<your instance of string[])

See?

Uurgh! That sounds completely the wrong way round to me. I believe in
writing docs before code - otherwise you're writing up the
implementation rather than the interface, effectively.

Differnet teams are different - but for us this is well established and
fits our needs as well as model very well.

Your programmers may rarely doc, but that's not been my experience in
other open source projects. The documentation quality does vary
considerably, but various projects manage perfectly well with the
developer docs in the source.

Everyone of our guys hated it. Made a complete mess of souce and was full
of tags, erorrs, and horrible things.

But really - lets not worry about docs. How we do it internally does not
affect .net users. We'll get XML outputs.

Sure - but that doesn't mean it's a valid objection *now*.

It is because Indy is that old. Even if we wanted - who would go through
and put all that stuff back in the code? Where we dont want it anyways.

To match it against argument names etc still requires embedded tags, which
is prone to errors and ugly. It like writing and RTF in notepad.

No it wouldn't - because "Indy" is much easier to read than "TId". Once
again, I don't believe you're able to really see the point from my
perspective, because you're so used to TId as a prefix.

No, I can see it. But when Im in .net, it doesnt bother me that things dont
have a T. Or lets pretend .net DID use Cs. It wouldnt bother me. A class
name is a class name. If I use a 3p library and all their classes were
MMFile for say a company called Micro Mush it wouldnt bother me.

No need - so long as you've got a decent tool

How would a tool solve the adaptor problem though? The renames I can see,
but the adaptors?

Why do you doubt it? IL isn't that complicated. I'd make the tool
modify the method body to do the conversions at the start/end of the
methods, as required, and change the method signature appropriately.

Aah - NOW we are talking. OK - I think we have a deal. We'll get XML docs
and we'll realias all the stuff on output. If you can handle this...

Is this a possible collaboration?

The only down side is this - with the adaptors we could make multiple ones.
ie for TSTream it coudl adapt to Stream, TextWriter, etc.... with this tool
it will map to ONE type for each.... So you'll have to pick ONE good
type...

In VCL its easy but in .net Im not sure of which ones, or if its even
possible to pick one.

You mentioned TextWriter, but remember, HTTP can fetch binary files
too.....



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Jon Skeet [C# MVP]]

Thats still quite a bit for such a small operation, espe when compared to
Delphi.

My point wasnt so much that its a lot, that with all this "chaff" will
users really care about:

new TIdCLRStream(ms)

vs

ms
?

It's not the amount of code that's in there - it's that there's another
type involved which needs to be understood when there's no need for it
as far as I can see.

We can make more adaptors VERY easily. This is a easier way than creating
many method forms. I dont mind adding adaptors at all.


There is one that returns a string actually already. I was just showing how
to use an adaptor in this example.

Right, that's fair enough.

But which is easier? Pre build we can do with a slightly advanced search
and replace added into our build too. And we already have have one because
of Indy being in otehr product and needing to be realiased to "Renamspace"
it. It currently only does the unit names, but could do classes without too
much trouble.

Right, if you've already got a tool which does most of it, there's not
much point in doing other things. There are advantages in doing it
post-build though - it can be more reliable because the assembly
information is easier to understand (to the computer) than the text -
it's easier to tell the difference between a variable name and a type
name, for instance.

How without inheriting new classes and having to maintain all those
variants?

By modifying the signature and method body directly, and putting the
conversion in the method.

Not at all - in fact:

1) I couldnt stop you. The Indy license permits this and much more.

2) If you or a VS team wants to maintain all these variants or additions,
problem is solved!

Thats what I was trying to express in my first message. We are looking for
VS people to work WITH.

Righto. I'll wait until the XML docs are ready, then "play" with it a
bit more to get a feel for what I think could be improved from a .NET
point of view, and then see what still grates at that stage.

A fair bit. My company is doing a lot of .net and so are many of the Delphi
people, but most of them are using Delphi for .net.

If they're using Delphi for .net, are they likely to be using the TId
conventions etc? What I guess I was asking before is how inviting you
want to make it for VB.NET/C#/MC++ users, rather than Delphi/Delphi.NET
users.

The naming convention is quite solvable. Its issue #3 that is a real
sticker IMO.

Issue 3 is the least important one to me, which sounds like we're
making progress (especially if issue 3 can be reduced in the ways we've
been discussing).

 

[Jon Skeet [C# MVP]]

You mean TIdEvent?

Eh? No, I mean the fact that I'm seeing TEventNewNewsList as a type

Those would all be redone as part of the renaming. We are working on a
rename utilitly now as it looks like we iwll need it for something else
too.
Cool.


The Indy ones you mean? TIdEventXXX?
Yup.


Or is it because its "not delphi"? That is how much user "revulsion" is
preference and how much is Delphi "T"?

It's because "IndyWebClient" makes sense when said aloud, but
"TIdHTTP" doesn't.

But what if was C++ and single source between Native and .Net?

I would have to consider how important the .NET user experience was. If
I considered it important, I'd either fork or use some kind of
renaming. Naming conventions are very important to me, as you may have
noticed

Please take a quick gander - its not very long:
<http://www.atozed.com/indy/Texts/VSIntro.iwp>

Hmm... it seems that I can get away from using TStrings, but only by
using TIdStringArray. It's still the same problem: there's a perfectly
good way of representing a string array in .NET, namely String[]. The
original complaint is having to learn classes which are effectively
unrelated to the network protocol I'm trying to use.

I think you missed the point again..... You dont use TidStringArray. Its a
"dummy" class. It works just like TIdCLRStream.

You use strings[], just when you call Indy that needs a TStrings you pass

new TIdStringArray(<your instance of string[])

See?

No, because I'm still *using* TIdStringArray. Wherever I currently have
to see *anything* to do with TIdStringArray, I should just be able to
pass a string[]. I shouldn't need to know that TIdStringArray exists -
it's a redundant concept as far as I'm concerned.

It is because Indy is that old. Even if we wanted - who would go through
and put all that stuff back in the code? Where we dont want it anyways.

To match it against argument names etc still requires embedded tags, which
is prone to errors and ugly. It like writing and RTF in notepad.

It's less prone to errors than you might think, when implemented
properly:

1) VS.NET will fill a lot of stuff in for you automatically
2) The compiler will give warnings/errors for tags which aren't valid,
or others which are missing.

No, I can see it. But when Im in .net, it doesnt bother me that things dont
have a T. Or lets pretend .net DID use Cs. It wouldnt bother me. A class
name is a class name. If I use a 3p library and all their classes were
MMFile for say a company called Micro Mush it wouldnt bother me.

I guess we're different then - I know for certainly that it would
bother me. Perhaps it's because I always sound code out in my head to
some extent and "TId" interrupts the flow so much.

How would a tool solve the adaptor problem though? The renames I can see,
but the adaptors?


Aah - NOW we are talking. OK - I think we have a deal. We'll get XML docs
and we'll realias all the stuff on output. If you can handle this...

Is this a possible collaboration?

It's certainly a possible collaboration, but I wouldn't put it into any
timelines at the moment. It's definitely feasible, but I have a 46 day
old son to look after as well as a full time job and answering
questions here (and various other commitments). I'd also be wanting to
write a relatively general-purpose IL refactoring tool rather than just
one for Indy, which would make it more flexible but obviously it would
take longer.

The only down side is this - with the adaptors we could make multiple ones.
ie for TSTream it coudl adapt to Stream, TextWriter, etc.... with this tool
it will map to ONE type for each.... So you'll have to pick ONE good
type...

Sure - or, of course, the tool could generate overloads for method
parameters, if we really wanted to get flashy

In VCL its easy but in .net Im not sure of which ones, or if its even
possible to pick one.

You mentioned TextWriter, but remember, HTTP can fetch binary files
too.....

Indeed. The thing is, I'd make the Get method either return an object
that encapsulated the entire response (status, headers, etc) or just
*return* a stream rather than *taking* one. At that stage things become
much simpler:

using (StreamReader reader = new StreamReader (http.Get("..."),
Encoding.ASCII))
{
result = reader.ReadToEnd();
}

However, obviously I'm not suggesting you change the way all your
libraries work internally. I'd have to look at it all in more detail -
this is only weekend musings at the moment. Speaking of which, it's
time for bed I'm afraid...

 

[Chad Z. Hower aka Kudzu]

It's not the amount of code that's in there - it's that there's another
type involved which needs to be understood when there's no need for it
as far as I can see.

Well .net is pretty darn "chatty" for Delphites. Many "simple" things in
Delphi turn into a few lines of code and pasing from 2-3 objects to each
other like that stream to text example, or saving listboxes to streams, or
files etc..

Right, if you've already got a tool which does most of it, there's not

Well we have a tool that does say 25%, and we are building the other 75% as
we speak. Its not actually for Indy, but we'll donate it to the Indy
project. I have one of our team building it now for some other purpose.

much point in doing other things. There are advantages in doing it
post-build though - it can be more reliable because the assembly
information is easier to understand (to the computer) than the text -
it's easier to tell the difference between a variable name and a type
name, for instance.

Well kind of - depends what you are doing. If its compmlex parsing of text
yes - but we can parse this limited amount and modify very easily before we
coudld even find the docs to read an assembly let alone code to read it.

By modifying the signature and method body directly, and putting the
conversion in the method.

I really like this idea.

Righto. I'll wait until the XML docs are ready, then "play" with it a

I cant give an estimate yet - we are evaluating existing as well as new
tools. But optimisticly in a week or so. Thats optimisitcly though.

If they're using Delphi for .net, are they likely to be using the TId
conventions etc? What I guess I was asking before is how inviting you
want to make it for VB.NET/C#/MC++ users, rather than Delphi/Delphi.NET
users.

Well it depends... Delphi 8 (Delphi.net) has FCL + VCL for .net. So we can
still use VCL on top of FCL. Most Delphi users will use a mixture as VCL is
not only familiar, but much easier for many tasks and it actually adds
quite a bit to FCL.

So for Delphi code - yes they will contine with T. (The Id was Indy prefix,
often "vendors" choose two letters). Rememeber - most Delphites are doing
..net AND Win32 and someitmes Linux with ONE set of souce code. So Delphites
are maintaining Win32 code and at the same time doing .net work.. one
language, one set of code etc.. Its really cool.

So yes - they want T. They dont want to ifdef their code up just because.

I think as D8 takes hold the Borland assemblies will become common on
machines and we can issue static linked versions of Indy removing all the
1.5 mb of Borland stuff. We cannot right now because of a license snafu in
the redistributable license. Borland is addresing this issue and said it
will be fixed, but corporate legal types dont work overnight.

Issue 3 is the least important one to me, which sounds like we're
making progress (especially if issue 3 can be reduced in the ways we've
been discussing).

Sounds good. Give us a few days and we'll get a new assembly. While you
only "see" me there is a team of 40 or so behind the scenes I am working
with. Only about 6 are active at a time, but those 6 are usualy very very
active and there is a LOT of work going on both for .net and Indy in
general.

Wait till we go visual like it is in Delphi. That will really smoke some vs
users.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Chad Z. Hower aka Kudzu]

I guess we're different then - I know for certainly that it would
bother me. Perhaps it's because I always sound code out in my head to
some extent and "TId" interrupts the flow so much.

Visually we skip it or say Indy. Its like any acroynym, or shortie in
messages. IIRC - what did you read? IIRC? AFAIK? CYA?

write a relatively general-purpose IL refactoring tool rather than just
one for Indy, which would make it more flexible but obviously it would
take longer.

But can work for Indy before its done.

Sure - or, of course, the tool could generate overloads for method
parameters, if we really wanted to get flashy

That would be even better IMO. It would leave the old ones there though - but
Delphi programmers will wnat them if they choose to use the "Net"- version
which they mgiht if they do mixed C# / VB / Delphi work.

However, obviously I'm not suggesting you change the way all your
libraries work internally. I'd have to look at it all in more detail -
this is only weekend musings at the moment. Speaking of which, it's
time for bed I'm afraid...

What? Its only 2:49am on this side of the planet.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Chad Z. Hower aka Kudzu]

What? Its only 2:49am on this side of the planet.

I see now that we are on the same side of the planet. Im just in a colder
locale to the north and east quite a ways... at least for 2 more weeks till I
go to my normal much warmer winter locale to the south east a ways from you.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Jon Skeet [C# MVP]]

I really like this idea.

I've had two more thoughts on this:

1) It might be easiest temporarily to work with the IL assembly code
itself - i.e. run ildasm on the assembly, run something which changes
the IL assembly code, then ilasm to reassemble it. That would allow us
to try a few different options relatively easily, I think.

2) Can you specify implicit conversion operators in Delphi? I don't
generally like them, but if there were implicit conversion operators
to/from the adaptor classes, that might give a "pretty good" solution
in one fell swoop. The developer would still see TIdStringArray in
signatures, but could basically ignore it. This could be a cheap way of
getting *almost* all the way there.

 

[Chad Z. Hower aka Kudzu]

1) It might be easiest temporarily to work with the IL assembly code
itself - i.e. run ildasm on the assembly, run something which changes
the IL assembly code, then ilasm to reassemble it. That would allow us
to try a few different options relatively easily, I think.

Yes. Thats a very good idea.

2) Can you specify implicit conversion operators in Delphi? I don't
generally like them, but if there were implicit conversion operators
to/from the adaptor classes, that might give a "pretty good" solution
in one fell swoop. The developer would still see TIdStringArray in
signatures, but could basically ignore it. This could be a cheap way of
getting *almost* all the way there.

Im not quite following. Can you explain a bit?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[William Stacey]

Socket question for ya. Want a udp server to listen and reply on port n.
Want one thread as just the listener and one thread as just the sender
sharing the socket. The doco says updclient and socket are not thread safe,
however others say that doing a send on one a receive on another is ok -
just don't have two threads both doing sends or receives on the same socket.
I tried using seperate sockets all together and using IPAddressReuse.
However that is a problem, because the sender sometimes gets the receivers
data, and cause it never calls Receive, the dgram is lost. TIA

 

[Jon Skeet [C# MVP]]

But lets assume they are single source, and still have to support native MFC.
ie, its one source code base.

Then I would attempt to do the same kind of name changing I'm
suggesting here.

Would people hold the same standard as they would to Delphi or say "Well its
MS code, its ok".

I don't know about anyone else, but *I* would hold it to the same
standard. MS gets no special dispensation from me.

 

[Jon Skeet [C# MVP]]

Yes. Thats a very good idea.

Much less work, too

However, thinking about it, changing the method signatures will break
anything internal that calls the method. Adding overloads avoids that
problem - but doesn't help for return values. This is what comes of
designing solutions late on a Saturday night (That doesn't mean the
idea doesn't have merit, just that it obviously needs more thought.)

Im not quite following. Can you explain a bit?

Sure. In C# you can specify implicit or explicit conversions between
types. For instance, here's a program which demonstrates a type (name)
which can be implicitly converted to and from a string:

using System;

public class Name
{
string value;

public Name(string value)
{
this.value = value;
}

public static implicit operator string (Name name)
{
return name.value;
}

public static implicit operator Name (string value)
{
return new Name (value);
}
}

public class Test
{
static void Main()
{
// Implicit conversion from string to Name
Name x = "Jon";
// Implicit conversion from Name to string
string y = x;
}
}

 

[Chad Z. Hower aka Kudzu]

Socket question for ya. Want a udp server to listen and reply on port

Probably should have started this as a new thread, but I'll reply here so you
see it.

n. Want one thread as just the listener and one thread as just the
sender sharing the socket. The doco says updclient and socket are not
thread safe, however others say that doing a send on one a receive on
another is ok - just don't have two threads both doing sends or receives

On the socket level it is perfectly acceptable. But who knows what the .Net
SDK does besides the socket calls. Thats one thing I really miss in .net vs
VCL is source. In VCL we always had source to see what was going on, often
even the intent.

You are probably safe to do it - assuming the .net class does not share some
variables between read and write routines. The could be sharing some kind of
event handle if its resouce intensive. So really its a pot shot.

But the socket itself definiteliy supports it, and I can tell you that Indy
for sure supports it. Want to use the Indy UDP classes?

on the same socket. I tried using seperate sockets all together and
using IPAddressReuse. However that is a problem, because the sender
sometimes gets the receivers data, and cause it never calls Receive, the
dgram is lost. TIA

Yes. Thats exactly what happens when you force two UDPs on the same port. You
dont want that in your case.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Chad Z. Hower aka Kudzu]

However, thinking about it, changing the method signatures will break
anything internal that calls the method. Adding overloads avoids that

Yes that would be a problem. The protocol methods are normaly endpoints and
are not called from internally, but many middle classes have methods that are
used by users.

problem - but doesn't help for return values. This is what comes of
designing solutions late on a Saturday night (That doesn't mean the

Indy typically uses var (by ref) arguments when its not a simple type. But
there are a few instances of TStrings as a result IIRC. We could maybe map
them to ones that use by ref calls and keep the existing ones as well?

Sure. In C# you can specify implicit or explicit conversions between
types. For instance, here's a program which demonstrates a type (name)
which can be implicitly converted to and from a string:

Delphi only supports thes in Delphi.net (AFAIK), not previous versions.

If it did - how would this help our situation though? And remember - these
are not just valued classes. They are actual classes with methods that Indy
uses, so Im not sure that this is workable either.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[William Stacey]

Thanks Chad for confirming that for me. I suspected the same. I will try
your library. Cheers!