On 11/19/01 4:14 AM, "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>
wrote:
> [EMAIL PROTECTED] writes:
>
>> Log:
>> Rewrite to support is<foo> boolean property introspection. So now it does
>>
>> getFoo
>> isFoo
>> getfoo
>
> Argh, it should be Jons' job to cry out loudly that we _again_ change
> the sematics of
>
> #set ($bar = $foo.Bla)
>
> is this really necessary just to be save two small letters? This may
> introduce bugs into existing and working templates. Lots of stuff
> surely has
Argh. Is is really necessary to exaggerate like that? When did we last
change the semantics?
>
> public void setFoo(String xxx)
> public String getFoo()
> public boolean isFoo()
>
> methods where implicit calling will now further confuse people. And
> all with without having implicit casting between types.
>
> Now you may be in the schizophrenic situation that before this checkin
> this worked:
>
> --- cut ---
> #set ($foo = $bar.foo)
> My foo is $foo
> --- cut ---
>
> and now it does not, just because I did call the getfoo() method in
> the bar object which returned a String and now I call the hasFoo()
> method which returns a boolean.
>
> Ok, it may be "bad style in my object" but nevertheless, this is a
> _semantic_ change which is IMHO a bad thing.
Fine. That's why I noted the situation with putting isFoo() before getfoo()
If we restore the order to
getFoo()
getfoo()
IsFoo()
Then it gets better.
Of course, if you are going to stick to your guns, you will then say
"Argh. It should be Jons job..."
Because what it should be is
getfoo()
getFoo()
isFoo()
To be compatible with what I could consider a bug of sorts in the previous
incarnation, because if you are a lunatic and have
getfoo()
and
getFoo()
In your class, then your stuff will break.
So if I return it to
getfoo()
getFoo()
isFoo()
Then things are better, but still broken if you also have a
get(String)
in the same class, as what we want is to be 100% backwards compatible with
previous mistakes, I guess, so what I really need to do is change it to
getfoo()
getFoo()
get("foo")
isFoo()
which certainly is fine my me.
>
> Can we please at least make this configureable with a switch.
>
>
> BTW: I would very much prefer to make the template language a little
> more "noisy". How about
>
> $foo.<bar> for calling getBar()
> $foo.[bar] for calling isBar()
Argh. Why don't you just do
$foo.getBar()
and
$foo.isBar()
???? Other than the 3 and 2 character savings, respectively, it certainly
is easier to understand when reading the templates....
> ;-) (ok, I shut up now. ;-) :-) )
>
> Regards
> Henning
>
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>