Page 1 of 1
Normalized syntax for LinkedList assignment commands
Posted: Wed Sep 02, 2009 5:20 pm
by Blue
I find the existing syntax/process for adding elements to linked lists quite surprising.
It's not in keeping with the rest of the PureBasic commands.
Most PB commands adhere to a regular syntax:
as in
Code: Select all
--> SetGadgetText(#Gadget, Text$)
--> ToolBarToolTip(#ToolBar, ButtonID, Text$)
--> AddDate(Date, Field, Value)
Once you know the syntax of one command, you know it for them all.
It makes working with the language easy: you may forget the exact wording of a command, but you never have to struggle with the syntax: it's always the same... or almost !
When it comes to Linked Lists, unexpectedly, things diverge.
Where you expect...
Code: Select all
--> AddElement(Queue(), value)
--> InsertElement(Queue(), value)
in keeping with the usual, regular, PB way,
you discover a 2-step process:
Code: Select all
AddElement(Queue()) ; create the element in memory
Queue() = value ; give it a vakue
InsertElement(Queue())
Queue() = value
I find this syntax counter-intuitive.
It would be great if the syntax of those 2 commands was normalized in the usual PB way.
As well, i'd like to point out an
omission in the Help file index:
the
NewList command does not appear in the list of available commands under the
LinkedList section.
Posted: Wed Sep 02, 2009 6:25 pm
by Kale
I Agree
Posted: Wed Sep 02, 2009 6:41 pm
by freak
And what type does the value have ? What about structured lists ?
Posted: Wed Sep 02, 2009 6:58 pm
by Kaeru Gaman
indeed.
you would need a structured dummy element to pre-store the values and pass it byRef, i.e. a pointer to it in AddElement.
in my exes is this highly counterproductive.
where should be the advantage of this:
Code: Select all
Define Dummy.Struct
Dummy\Name = "Washington"
Dummy\FirstName = "Leroy Fiztgerald"
Dummy\Addr = "Park Ave 23"
Dummy\Town = "Beverly Hills"
Dummy\ZIP = "90210"
Dummy\Phone = "1-800-555-0123"
Dummy\Account = "235679234"
AddElement( Customers(), @Dummy )
compared to this:
Code: Select all
AddElement( Customers() )
Customers()\Name = "Washington"
Customers()\FirstName = "Leroy Fiztgerald"
Customers()\Addr = "Park Ave 23"
Customers()\Town = "Beverly Hills"
Customers()\ZIP = "90210"
Customers()\Phone = "1-800-555-0123"
Customers()\Account = "235679234"
Posted: Wed Sep 02, 2009 7:26 pm
by Joakim Christiansen
freak wrote:And what type does the value have ? What about structured lists ?
1+
Posted: Wed Sep 02, 2009 8:57 pm
by Kale
freak wrote:And what type does the value have ? What about structured lists ?
Point well taken, argument withdrawn.
Posted: Thu Sep 03, 2009 1:34 am
by Blue
freak wrote:And what type does the value have ? What about structured lists ?
At present, you write (snippet from your breadth-first search with a queue)
Code: Select all
NewList Queue.s()
AddElement(Queue())
Queue() = "C:"
to declare a linked kist of string elements, don't you?
If the syntax was
Code: Select all
NewList Queue.s()
AddElement(Queue(), "C:"
wouldn't that be exactly the same? The type declaration wouldn't change, but the assignment to a new element would be written in the familiar PB fashion. Where we have 2 steps (create the memory structure followed by an assignment), we'd have only one.
I don't know the underlying plumbing of PB, so maybe i'm skipping too lightly (and very innocently) over important considerations here.
But from my point of view, a user's point of view, the suggested form appears as a just a different way of writing the same thing. And I'd much prefer that one to the present one.
Of course, from your point of view, the Master Plumber's POV, the whole suggestion to combine the current 2 steps into one may appear totally unrealistic because of things that i don't even suspect.
So, my simple answer to your original question, would be, for the time being, "Humm... I don't really know."
If you think such a change is mission impossible, so be it. Too bad.
But i definitely find the current construction strange and un-PB like !
Posted: Thu Sep 03, 2009 1:55 am
by Blue
Kaeru Gaman wrote:indeed.
you would need a structured dummy element to pre-store the values and pass it byRef, i.e. a pointer to it in AddElement.
in my exes is this highly counterproductive.
[...]
Very good demonstration of why my suggestion wouldn't make sense in many cases.
As i mention in my answer to Freak, just above, i don't know all the ins & outs of using linked lists. I was of course thinking of elements as single discrete values of basic types.
With your example, I can see why things are done the way they are presently.
Thanks, Kaeru Gaman.
Posted: Thu Sep 03, 2009 8:39 am
by Kaeru Gaman
you're welcome.
... in my eyes, using structures elements is the essential use of LList.
I coded in PB and used LLists for two years or so, before I realized it is even possible to assign simetype elements to a LList.
I had never tested it, because it just was of no use at all for me.
when I have single type elements, I need at least some kind of reference that makes up an order, so I use an Array to have an Index...
Posted: Thu Sep 03, 2009 12:13 pm
by Fred
You can indeed do a procedure if you want one call access all accross your program.
Posted: Thu Sep 03, 2009 9:46 pm
by Blue
Fred wrote:You can indeed do a procedure if you want one call access all accross your program.
Good point, indeed, or a macro.
Thanks for the input
However this was not so much about something i wanted, in a practical way, as much as something i perceived as being at odds with the rest of the language.
Kaeru Gaman's example opened my eyes.
I never thought of Linked Lists in that way. Now, of course, it's all so very obvious !!! Pfttt...
May i suggest that
Kaeru Gaman's example, or something very similar, be
added to the Help file's examples. That would better demonstrate some practical use of Linked Lists.