On 11/19/01 8:29 AM, "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>
wrote:
> "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes:
>
>> On 11/19/01 4:14 AM, "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>
>> wrote:
>
> Hi,
>
> sorry if this came over wrongly. I didn't want to flame you. :-(
>
No worries! I thought it was funny, as I tried to keep the
"Argh. .... Jon .... " riff going - I should have tossed in a smiley - first
post before coffee...
> While I see the reason for this change, I also see the questions in
> the .users list about "not working" references, which sometimes
> translate to the fact that $foo.Bar must be explicitly return a String
> or else you must write $foo.getBar()
Why must it return a String? I don't recall any such restriction.
> (If we would have implicit type casting then you wouldn't have these
> effects)
>
> And IMHO we already have a fair amount of guessing what
>
> $foo.Bar
>
> really means. It could be
>
> public String getBar()
> public boolean isBar()
> public String getbar()
> public Object get("Bar")
>
> Quite a lot of meanings for just one innocent expression.
Yes, I agree sort of. This is the problem with the whole 'support' of the
bean spec, as it's meant for discovery of properties based on defined
methods, not discovery of methods based on a hint about a property.
> I wrote just last week, that I gave up writing the short cut
> expressions just for the sake of not running into errors. I work with
> velocity for about half a year now and I still make mistakes when
> using $foo.Bar :-)
I don't understand that one (if you are referring to the String thing...)
However, I will admit to adoring the whole bit about not really knowing what
$foo.bar
Actually maps to - I exploit this all the time, being able to interchange
objects in the context for a specific template, knowing it just has to
support a property 'bar' *somehow*.
I tend to think of there being a strict 'data contract' between me (the
programmer) and the template, so I just stick to what I have agreed to, the
implementation being up to me, the programmer.
> And IMHO it is a source of silent errors just because there are
> different return types. Consider this:
>
> #set($foo = $bar.get($pulltool.Ready))
>
> with
>
> class Bar
> {
> public Object get(String xxx);
> }
>
> class Pulltool
> {
> public boolean isReady();
> }
Right - that wouldn't work.
>>> $foo.<bar> for calling getBar()
>>> $foo.[bar] for calling isBar()
>
>> Argh. Why don't you just do
>
>> $foo.getBar()
>
>> and
>
>> $foo.isBar()
>
> That above was a joke. Sorry. I should've written @$foo.Bar and
> %$foo.bar to make it clearer what I was aiming at (perl).
Oh no... :)
This is a good conversation about this - I am just about to check in a
reversal of last nights, restoring the same discovery pattern for a property
to be
get<property as is>
get<property with 1st letter flipped>
get( "property" )
And *then* followed by
boolean is<Property>
The idea being we should decouple these, and restore whatever broken
semantics - we can discuss and decide to fix the semantics if we want
independent of the conversation about including boolean is<Property>
support.
So I will check in, and people can play and give their USD 0.02 (which I
think is DEM 0.0445)
Geir
> Regards
> Henning
>
> P.S.: If I recall correctly, last time we changed semantics was when
> we made the Introspector more smart about public and protected
> interface to allow a certain kind of loops over Map.Entry ;-) No,
> really, I did like the change.
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
