fbpx
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: Instantiation syntax - our own Classes etc.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #1

  • Phil Hepburn
  • Phil Hepburn's Avatar Topic Author
  • Offline
  • Posts: 737
  • Karma: 7
Hi Robert, Team and guys,

I am trying to provide in my LINQ eNotes a better way to 'Select' than to use an anonymous type, when it then causes issues afterwards - to access elements and their properties.

I have followed Nick's advice and made myself a working 'concrete' class call "EightP2S".

The attached image shows the working code but also a couple of commented and failed code attempts by me, to find some alternative syntax for specifying the property values at the point of instantiation - all in the 'select' clause.

I would like a much tighter version of line 82, and one where the string values for City and Email could not get mixed up (swapped around) just because I got my positioning (placement) wrong in my code. The compiler would not complain at my mistake!

Please can you help and make some suggestions etc.,
Cheers,
Phil.

Cheers,
Phil.
Attachments:

Please Log in or Create an account to join the conversation.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #2

Phil,

The syntax for Named arguments is
: <Identifier> := <Expression>

at this moment.

Try this:
FUNCTION start AS VOID   
	VAR oPerson := Person{ :LastName := "Hepburn" , :FirstName := "Phil" }
	? "F", oPerson:FirstName
	? "L", oPerson:LastName  
	Console.ReadLine()	
	
CLASS Person
	PROTECT _firstName AS STRING
	PROTECT _lastName  AS STRING	                                        
	PROPERTY FirstName AS STRING GET _firstName PRIVATE SET _firstName := VALUE
	PROPERTY LastName  AS STRING GET _lastName  PRIVATE SET _lastName := VALUE
	CONSTRUCTOR (FirstName AS STRING, LastName AS STRING)
		_firstName := FirstName
		_lastName  := LastName
		RETURN
END CLASS


I will talk with Nikos to see if we really need the colon before the argument name...

Robert
XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #3

  • Phil Hepburn
  • Phil Hepburn's Avatar Topic Author
  • Offline
  • Posts: 737
  • Karma: 7
Hi Robert - thanks,

I have no real issue with a colon at the moment - BUT - I can't seem to get this syntax to work - can you have a quick look at the attached images.

Am off to take my wife for her car.

Speak soon,
Phil.
Attachments:

Please Log in or Create an account to join the conversation.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #4

Robert wrote: I will talk with Nikos to see if we really need the colon before the argument name...
Robert

Yes, please. Already to many dots on the screen ;)

Please Log in or Create an account to join the conversation.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #5

Phil,
The argument name in the constructor call must match the parametername in the parameterlist of the constructor.
In your constructor you have used the parameter names cM, cE, cC, dtDB.
You are now trying to assign the properties. That is something different.
I know that C# has a syntax where you can do that :
var person = new Person
                    {
                         FirstName = "Phil",
                         LastName = "Hepburn"
                    };

But this is something different. In that case you care calling a constructor without parameters and then you are assigning values to the properties.
CSharp calls this an ObjectInitializer() in stead of an Object constructor iirc.

The syntax that I used before is using a parameterized constructor.
We will have a look at how C# implements the ObjectInitializer and maybe we will come with a good syntax for that later.
Something like this maybe:
var person := Person {{ FirstName := "Phil",LastName := "Hepburn }}

Do you have a suggestion ?

Robert
XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

Last edit: by robert.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #6

  • Phil Hepburn
  • Phil Hepburn's Avatar Topic Author
  • Offline
  • Posts: 737
  • Karma: 7
Hi Robert - Thanks yet again for your prompt and sensible / constructive reply, and positive comments.

I understand the current situation and have it working for me and my eNotes material - "great stuff".

I attach an image or two to show what I have, and to allow a possible short statement from me as to what I would like, and / or may make sense to others ?!

I have renamed the arguments in the Constructor to be more meaningful than 'cC' and 'cE' etc.
I have also tried the swapping around of 'inputs' when specifying the new object - this seems to work okay, so we can have any order as of now ;-0) Presumably we have to input arguments for all four, as this is the 'pattern' (signature) of the possible Constructor, other than the empty one.

Now then, I suggest that if possible, we need to have an Intellisense reminder of what the constructor arguments are - most essential I feel, if we are to keep this approach.

However, I am NOT at all sure I like a public face to the 'in-method' argument variables that I usually use for my own and VERY private use - for my eyes ONLY!

Also, what if we have Constructor overloads with different argument variables ? The properties on the other hand will stay the same for all Constructors.

Can we come up with a syntax that would allow us to be restricted to using public property names, and these to be in the Intellisense list ? - for ease of coding.

For now I am happy to go ahead with my research and eNote creation with things as they are, and make a note to readers that this could change and improve over the coming months.

We are getting close to what we can do in C#, and xbase (X#) is managing to do a whole heap that I like and enjoy, and to be honest, never thought that I would ever see.

But it would be nice to be able to do as in C#, they have obviously thought things through pretty well, whatever some of our colleagues say about MS and their staff.

Hope all this makes sense and is useful in some way or another.

Kindest Regards,
Phil.
Attachments:

Please Log in or Create an account to join the conversation.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #7

This could get confusing!
var person = new Person { FirstName = "Phil", LastName = "Hepburn" };
As you mention, this is really
var person = new Person() { FirstName = "Phil", LastName = "Hepburn" };
ie. instantiating the object with a parameterless constructor and then setting the properties.

So for consistency I would have thought it ought to be more like
var person := Person{} { FirstName := "Phil", LastName := "Hepburn" }
Otherwise it looks as though you're passing an array into the constructor. Also this way you get to start using curly brackets properly in X# ;-)

Nick

Please Log in or Create an account to join the conversation.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #8

Nick,

var person = new Person { FirstName = "Phil", LastName = "Hepburn" };

As you mention, this is really
var person = new Person() { FirstName = "Phil", LastName = "Hepburn" };
ie. instantiating the object with a parameterless constructor and then setting the properties.

So for consistency I would have thought it ought to be more like
var person := Person{} { FirstName := "Phil", LastName := "Hepburn" }
Otherwise it looks as though you're passing an array into the constructor. Also this way you get to start using curly brackets properly in X# ;-)


Thanks for the suggestion. You are right about the confusion, especially since the class Person could have a constructor with an Array parameter. And in that case it would get really confusing (although the <Name> := <Expression> would normally not appear in a literal array).

Robert

Robert
XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

Last edit: by robert.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #9

Phil,
The intellisense thing is import, we are aware of that. But is also complicated, especially since you normally are mixing uncompiled (source) code with compiled code in referenced assemblies.

To reiterate (in C# syntax for now), there are 2 syntaxes that you can use to construct objects in C#:
var oPerson := new Person( First = "Phil", Last = "Hepburn")
and
var oPerson := new Person { FirstName = "Phil", LastName = "Hepburn"}
The first syntax uses (named) constructor arguments, the second syntax uses an object initializer.

The following pages on MsDn describes this as well:
https://msdn.microsoft.com/en-us/library/bb397680.aspx?f=255&MSPPError=-2147217396

The first syntax with the named arguments is supported in X# and requires the names to be the same as the argument names from the constructor.

The second syntax uses names that mutch match public (or internal) settable properties from the type. The second syntax also requires that there is a parameterless constructor for the type.
X# does not support the object initializer syntax yet, but we will add that (before Cologne, I am sure).

Intellisense should (and will eventually) list constructor parameters for the first method and public (settable) properties for second syntax.

Robert
XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #10

  • Phil Hepburn
  • Phil Hepburn's Avatar Topic Author
  • Offline
  • Posts: 737
  • Karma: 7
Hi Robert,

I am sure you will do me and all X# guys a good job, as usual. It all makes sense what you say and report back - its just a bit out of my league - experience, knowledge etc..

Help in Intellisense in some way(s) is very important I feel - as I found that when I did all my C# LINQ stuff I really found it most helpful, even deep into the LINQ query syntax, and the method syntax with Lambdas. The properties were all there ;-0)

Anything you can do to move us towards the C# situation will be most welcomed. I am sure you and Nikos will do us proud ;-0)

I can manage OK with what I have available at the moment, even driving VS without any intellisense at all !!!

Power to your elbow(s),

Regards,
Phil.

P.S. there are quite a few reasons to have to supply an empty Constructor - IIRC stuff related to WPF and data binding that I documented in the last two Cologne material set I provided.

Please Log in or Create an account to join the conversation.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #11

  • Phil Hepburn
  • Phil Hepburn's Avatar Topic Author
  • Offline
  • Posts: 737
  • Karma: 7
Hello again Robert,

Sorry, I have had a few days away from LINQ 'stuff' doing some house maintenance - replacing floor boards in a bedroom !! What a task.

However, I do have something positive to post, on the issue of 'in-line' instantiation. Since your last post, I had a play around and a think, and used the current compiler facilities to come up with some better, tidier, and easier to read syntax. The three attached and inserted small images will help explain all. Sorry the 'system' has inserted them in the reverse order to my selection, so checkout '_01' first, then '_02' and '_03'.

By naming the Constructor variables 'in_xxxx' where the X's represent the exact property names, then the code all gets a lot more understandable.

Hope this makes sense, but I would still prefer to use an empty Constructor and then specify (in any order) the property name and the value to be assigned. This way we can effectively have all possible overloads, as zero to 'N' inputs can be provided.

Regards to all,
Phil.
Attachments:

Please Log in or Create an account to join the conversation.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #12

  • Phil Hepburn
  • Phil Hepburn's Avatar Topic Author
  • Offline
  • Posts: 737
  • Karma: 7
Whoops ! - an Addendum :-

The last image shows that we can only be as tight in our code as our human frailties (inabilities) allows us to be.

If you check out the commented code and its related part, you see we can assign incorrectly as long as the type is correct, and the compiler is none the wiser ;-0)

Regards,
Phil.

Please Log in or Create an account to join the conversation.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #13

Phil,
You will be pleased to hear that we have added object initializers and collection initializers for the next build.

An example of the collection initializer:
FUNCTION Start AS VOID
LOCAL a AS ArrayList
a := ArrayList{}{1,2,3}
? a[1] 
     Console.Read()
An example of the Object Initializer, with a nested collection initializer for the Phones property.
Please also note that an AUTO property can have an initial value too, without a constructor !)
FUNCTION Start AS VOID
     VAR oPerson := Person{}{ Last := "Van Der Hulst", First :=
"Robert", Phones := {"123","456"} }
     ? oPerson
     Console.Read()


CLASS Person
     PROPERTY First     AS STRING AUTO
     PROPERTY Last      AS STRING AUTO
     PROPERTY Phones    AS List<STRING> AUTO := List<STRING>{}
     METHOD ToString() AS STRING
         VAR result := First+" "+Last
         FOREACH VAR p IN Phones
             result += " P: "+p
         NEXT
         RETURN result
END CLASS 

Robert
XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

Last edit: by robert.

Instantiation syntax - our own Classes etc. 2 years 4 months ago #14

  • Phil Hepburn
  • Phil Hepburn's Avatar Topic Author
  • Offline
  • Posts: 737
  • Karma: 7
Hi Robert,

This sounds really good, and also a VERY worthwhile step forward. I look forward to using it when you make it publically available. I certainly will have it in my examples and eNotes for Cologne.

For the moment I have plenty to keep me busy, apart from my floor replacement tasks ;-0)

Next on my list is to look at "LINQ to SQL" and create some X# samples and eLearning notes. There are a few things which differentiate LINQ to SQL from "LINQ to Objects", even though the basic / fundamental syntax code has many similarities.
Please give my best wishes to all the Team.

Cheers,
Phil.

P.S. I will make a note in my session material of what you posted - just so they know what is coming soon.

Please Log in or Create an account to join the conversation.

  • Page:
  • 1