|
« Return to Thread: Strange behaviour when using CAPS for a slot name
Re: Strange behaviour when using CAPS for a slot name
by joh_90uk
::
Rate this Message:
I agree and don't :) I agree that using CamelCase of constants isn't the IO convention, I am doing this as I am trying to replicate some legacy C code and want to follow the legacy conventions as close as possible (to show I am doing like for like when comparing the two sets of code). This is of course not ideal and I would not do this if I were writing from scratch.
However I do also think it very strange to have the action of an assignment vary dependant upon the name of the object being assigned to.
I don't agree that clone(someslot) affecting that slot is odd though any more than setSlot(someslot) affecting the slot is odd. I would suggest having the ability to do clone() which doesn't affect the slot and clone(someslot) which does affect the slot is fine - as long as it is documented.
And there in lies the real problem I think, that this unexpected behaviour is not documented, and indeed that the documentation clearly states that := will call setSlot, so to have it calling setSlotWithType() is distinctly unexpected :)
ChrisM
--- In iolanguage@..., Rich Collins <richcollins@...> wrote:
>
> Object clone("SomeProto") having the local side effect of setting a
> slot would be quite unexpected.
>
> I think the problem here is the convention of using capitalized camel
> case for both protos and constants. I personally don't believe in the
> idea of constants. I treat constants like normal message sends (as
> does Io: Number constants pi)
>
> On Jun 17, 2009, at 9:56 AM, joh_90uk wrote:
>
> >
> >
> > Would it not be better to do a look ahead for a clone if needs be,
> > rather than depend on capitalisation? Or alternatively have clone()
> > take a parameter with a slot name, giving.
> >
> > Object clone("SomeProto")
> >
> > instead of:
> >
> > SomeProto := Object clone
> >
> > It seems less "magic" and therefore less prone to confusion.
> >
> > ChrisM
> > --- In iolanguage@..., Rich Collins <richcollins@>
> > wrote:
> > >
> > > It avoids having to do this:
> > >
> > > SomeProto := Object clone setType("SomeProto") do( ...
> > >
> > > On Jun 17, 2009, at 6:17 AM, joh_90uk wrote:
> > >
> > > >
> > > >
> > > > The capitalisation of a variable name changes the behaviour of an
> > > > operator - that's not pretty! It's also not documented in the
> > guide:
> > > >
> > > > ::= Creates slot, creates setter, assigns value
> > > > := Creates slot, assigns value
> > > > = Assigns value to slot if it exists, otherwise raises exception
> > > >
> > > > These operators are compiled to normal messages whose methods
> > can be
> > > > overridden. For example:
> > > >
> > > > source compiles to
> > > > a ::= 1 newSlot("a", 1)
> > > > a := 1 setSlot("a", 1)
> > > > a = 1 updateSlot("a", 1)
> > > >
> > > > Luckilly ::= doesn't seem to have the same issue so I'll use that
> > > > instead (don't really want a getter/setter as it is a constant but
> > > > it'll do). Cheers,
> > > >
> > > > ChrisM
> > > >
> > > > --- In iolanguage@..., Jeremy Tregunna
> > > > <jeremy.tregunna@> wrote:
> > > > >
> > > > >
> > > > > On 17-Jun-09, at 8:29 AM, joh_90uk wrote:
> > > > >
> > > > > > Steve, I see rather strange behaviour when using caps for a
> > > > variable
> > > > > > name. See below:
> > > > > >
> > > > > > Io> 55 type
> > > > > > ==> Number
> > > > > > Io> aa:=55
> > > > > > ==> 55
> > > > > > Io> 55 type
> > > > > > ==> Number
> > > > > > Io> AA:=55
> > > > > > ==> 55
> > > > > > Io> 55 type
> > > > > > ==> AA
> > > > > >
> > > > > > So by using a caps slot name during a slot assignment, the
> > type of
> > > > > > the subject of that assignment is changed to the name of the
> > slot.
> > > > > > Not sure why this is happening but I'm guessing it was not
> > > > intended.
> > > > >
> > > > > You will see why if you run the following two code snippets:
> > > > >
> > > > > message(aa := 55) asString
> > > > >
> > > > > and
> > > > >
> > > > > message(AA := 55) asString
> > > > >
> > > > > This was a special case created a couple of years ago to avoid
> > > > manual
> > > > > setting of the type slot. But this is desired behaviour I
> > suppose.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Jeremy Tregunna
> > > > > jeremy.tregunna@
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>
However I do also think it very strange to have the action of an assignment vary dependant upon the name of the object being assigned to.
I don't agree that clone(someslot) affecting that slot is odd though any more than setSlot(someslot) affecting the slot is odd. I would suggest having the ability to do clone() which doesn't affect the slot and clone(someslot) which does affect the slot is fine - as long as it is documented.
And there in lies the real problem I think, that this unexpected behaviour is not documented, and indeed that the documentation clearly states that := will call setSlot, so to have it calling setSlotWithType() is distinctly unexpected :)
ChrisM
--- In iolanguage@..., Rich Collins <richcollins@...> wrote:
>
> Object clone("SomeProto") having the local side effect of setting a
> slot would be quite unexpected.
>
> I think the problem here is the convention of using capitalized camel
> case for both protos and constants. I personally don't believe in the
> idea of constants. I treat constants like normal message sends (as
> does Io: Number constants pi)
>
> On Jun 17, 2009, at 9:56 AM, joh_90uk wrote:
>
> >
> >
> > Would it not be better to do a look ahead for a clone if needs be,
> > rather than depend on capitalisation? Or alternatively have clone()
> > take a parameter with a slot name, giving.
> >
> > Object clone("SomeProto")
> >
> > instead of:
> >
> > SomeProto := Object clone
> >
> > It seems less "magic" and therefore less prone to confusion.
> >
> > ChrisM
> > --- In iolanguage@..., Rich Collins <richcollins@>
> > wrote:
> > >
> > > It avoids having to do this:
> > >
> > > SomeProto := Object clone setType("SomeProto") do( ...
> > >
> > > On Jun 17, 2009, at 6:17 AM, joh_90uk wrote:
> > >
> > > >
> > > >
> > > > The capitalisation of a variable name changes the behaviour of an
> > > > operator - that's not pretty! It's also not documented in the
> > guide:
> > > >
> > > > ::= Creates slot, creates setter, assigns value
> > > > := Creates slot, assigns value
> > > > = Assigns value to slot if it exists, otherwise raises exception
> > > >
> > > > These operators are compiled to normal messages whose methods
> > can be
> > > > overridden. For example:
> > > >
> > > > source compiles to
> > > > a ::= 1 newSlot("a", 1)
> > > > a := 1 setSlot("a", 1)
> > > > a = 1 updateSlot("a", 1)
> > > >
> > > > Luckilly ::= doesn't seem to have the same issue so I'll use that
> > > > instead (don't really want a getter/setter as it is a constant but
> > > > it'll do). Cheers,
> > > >
> > > > ChrisM
> > > >
> > > > --- In iolanguage@..., Jeremy Tregunna
> > > > <jeremy.tregunna@> wrote:
> > > > >
> > > > >
> > > > > On 17-Jun-09, at 8:29 AM, joh_90uk wrote:
> > > > >
> > > > > > Steve, I see rather strange behaviour when using caps for a
> > > > variable
> > > > > > name. See below:
> > > > > >
> > > > > > Io> 55 type
> > > > > > ==> Number
> > > > > > Io> aa:=55
> > > > > > ==> 55
> > > > > > Io> 55 type
> > > > > > ==> Number
> > > > > > Io> AA:=55
> > > > > > ==> 55
> > > > > > Io> 55 type
> > > > > > ==> AA
> > > > > >
> > > > > > So by using a caps slot name during a slot assignment, the
> > type of
> > > > > > the subject of that assignment is changed to the name of the
> > slot.
> > > > > > Not sure why this is happening but I'm guessing it was not
> > > > intended.
> > > > >
> > > > > You will see why if you run the following two code snippets:
> > > > >
> > > > > message(aa := 55) asString
> > > > >
> > > > > and
> > > > >
> > > > > message(AA := 55) asString
> > > > >
> > > > > This was a special case created a couple of years ago to avoid
> > > > manual
> > > > > setting of the type slot. But this is desired behaviour I
> > suppose.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Jeremy Tregunna
> > > > > jeremy.tregunna@
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>
« Return to Thread: Strange behaviour when using CAPS for a slot name
| Free embeddable forum powered by Nabble | Forum Help |
