xsharp.eu

When programming in C# a large number of new functionality in my programs starts from Stackoverflow or Codeproject code fragments which I first test to see if they actually work, then try to understand and then adapt to what I want it to do. This I do far more often then I ever did for VO; I still feel very uncomfortable with C# I must say, for more than one reason. Only good thing is that there are many code fragments with a reasonable percentage actually working.

I now use a function which adds GPS coordinates into a photo and then saves it. The working syntax is this:

Geotag(oImg, nLat, nLong).Save(cDestFile, ImageFormat.Jpeg);

After setting the so called EXIF values for GPS into the Bitmap passed as oImg the end result is saved to cDestFile.

But I do not know how. What does the dot between the call GeoTag and Save do? Apparently the return value of GeoTag (Bitmap oImg, after being adapted) is directly passed to the Save function, to be saved I'd say, so this must have some fancy name. Can anyone tell how this is called?

I know it's a C# question but probably it works like that as well in X#.

Dick

Hi Dick,
IMHO (and without looking at the documentation I would say that the C# code would result in a X# code as follows: The first part of the statement creates a GeoTag object, and the second part saves it to a file in jpeg format.

IMHO this is is a good sample why X# is more readable than C# and enhances therefore the maintability of software over years.

Wolfgang

My understanding: This dot in this case is called method chaining. If you have a valid object which has accessible methods, you can just chain them with the dot operator. The equivalent in X# is the colon operator. Even in VO if an object returns self, you chain the methods.

To add a bit more to what the guys already said: Dick, is there a "new" keyword, before this line of code? If not, then my guess is that Geotag() is a method of your class (or of a parent class) which returns an object of type Bitmap. Then the code is calling the Save() method of that bitmap, in one line.

Hello Wolfgang, Jamal, Chris,

Thanks for the explanations, and as I never heard about method chaining before (indeed that's what it seems to be) I've learned something new. There's no New operator but the method returns the processed bitmap. Once you know how it works I'd say it saves an extra line and some extra handling in your code while still being reasonably clear. Good to know it works in X# as well.

I agree with Wolfgang that X# is more readable in every aspect. Together with VS which does not allow to edit just one entity I often misplace a curly bracket or semicolon causing 15000 lines of other code in the program to turn red. In some cases it is not even clear at once that the error comes from the changes just made. It usually takes me quite a while before I discover where it is wrong. My method is to copy the new code to text editor and type Ctrl Z until I can compile again and then try line by line to apply the changes until I see what I did wrong.

A clear IF..ENDIF; FOR.. NEXT or DO.. ENDDO without all the unnecessary ; and {} is many times preferable.

This having said, I started this project in the Vulcan period from a C# Microsoft sample and for that reason it made more sense to continue in C# than convert it to X# first. But that choice definitely makes programming a lot more unpleasant :VS and C#!

Dick

Hi All

In this discussion it appears to me that you are all trying to rationalise and explain things through code and coding syntax.

The fact is that we, as human beings, all "see" things in our own individual way. This means that I cannot say "seeing things throuh code" is wrong. But what I can say is I could never explain things to myself, nor would I attempt to explain things to others in that way.

I would not try, in some way to mentally equate XSharp with C# (directly at any rate - far too difficult for my brain).

I would think of routes through a running program in terms of how we go about things in real life. Real Life in a 3-Dimensional world where we must always move forward in time. We can never go back in time - neither can our programs.

XSharp can be envisioned as working in 2 dimensions. (Threading perhaps being the third, but that is outwith our program straying into the O/S). 2 dimensional thought is what makes XSharp so much easier to understand.

C#, to garner its full capabilities, must be envisioned as working in 3 dimensions - that is the C# program itself, exclusive of threading.

I hope this makes some sense to some (as Phil may have said)

Terry

Terry,

You have lost me completely.
X# and C# are VERY comparable. They are so comparable that we are able to parse X# code and convert that into a C# parse tree. If we wanted to we could also do the reverse.

I don't see where the 1 dimension difference between the two is.

Robert

Robert,

Yes X# and C#, looked at as "Software Tools" for developing applications are very comparable.


What I am saying relates to a very different perspective from which digital computer operation, behind the scenes, may be viewed.

It is a perspective that I find makes things overall easier to explain. To myself at least.

It is a perspective that allows anyone to conceptualise what is happening when an application is actually running. eg see in advance where and why exceptions may be generated.

Furthermore, and perhaps more importantly, what I am trying to say can be proved scientifically, mathematically (statistics) and logically, to be correct.

I am clearly failing to make the rationale of all this clear in this post or previous postings on similar topics.

I ought try to put things together in a more comprehensive and cohesive paper, but although not too difficult to understand, it would cover a range of disciplines, and take a fair bit of time.

The 1 dimension difference is essentially a difference in what the application being developed is doing. Seldom do business applications require more than a 2-dimensional insight. Other applications that C# may be targetting could do.

The problem in trying to make all this clear is that there are no clear-cut demarcations between all these factors. Just as there are no clear-cut demarcations between what we are used to doing in real life.

Terry