You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Christian Edward Gruber <cg...@israfil.net> on 2009/02/11 03:54:58 UTC
local: in loops and strongly typed objects.
Hey Howard et. al.
I was thinking about the var prefix in loops which allow for
scalars to be held without having to create a property on the
component. I was wondering about an alternative. I recognize that
this mechanism doesn't use reflection, so cannot dynamically determine
the type of the object, hence the limitation. But I wonder if a
simple syntax change to allow type declaration would be suitable, such
that the component could determine type at compile time. What I'm
thinking would look something like:
<ol t:type="loop" t:source="listItems" t:value="${var:
(com.foo.bar.blah.MyObject)listItem}">
<li>${var:listItem.name}</li>
</ol>
In other words, it would explicitly provide a cast-like syntax to
allow the bytecode manipulation to be instructed with the type. Now,
I'm not 100% sure I think this is better than adding a single
@Property private MyObject listItem in the code, but because this is
truly a local variable for this iteration, it seems like having an
instance variable is not appropriate for the purpose. Also, I'm not
sure about whether such instance variables end up on the heap, since
they aren't created and destroyed on the call stack as are local
variables. (Mind you, I'm not clear on how the bytecode is
manipulated, so it could be that your pre-processing just creates an
instance variable and it's all the same.) I admit part of this is an
aesthetic choice, and I'm having real problems deciding which is more
appropriate.
It would be nice if you could get any type information from listItems,
but Java's generics are meaningless out at runtime, and even then,
it'd be runtime, not compile-time information you got back, so we're
back to reflection. God I miss informal protocols and selector-based
messaging in Objective-C... <sigh> If only Javasoft had listened when
all us NeXTSTEPers bitched and complained about its absence...
Anyway, I'm just putting it out there for comment. Essentially
extending the var: binding's format with optional cast-alike syntax.
cheers,
Christian.
Christian E. Gruber - President / Senior Consultant
Isráfíl Consulting Services Corporation
email: cgruber@israfil.net
mobile: +1 (289) 221-9839
web: http://www.israfil.net/
"...keenness of understanding is due to keenness of vision."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: local: in loops and strongly typed objects.
Posted by Christian Edward Gruber <ch...@gmail.com>.
This all makes good sense, and frankly it's such a small nit, it
almost doesn't matter. My main earlier complaint about loops and
local variables (essentially my dislike of boilerplate code) was
already handled by the creation of the @Property annotation, so really
it's as I said, and aesthetic thing. You don't have to unit-test a
single private variable, so that's clean. I just don't like having a
variable that's only used by external code (even if auto-generated).
Feels un-encapsulated. But these arguments from Howard and Thiago are
compelling, and I was waffling about this anyway. This is part of the
reason I didn't JIRA it - I suspected it wasn't really worth doing,
unless there was an easy way we just hadn't thought of. Before seeing
T5 in action, I would have argued to have it work with reflection to
eliminate the code, but frankly this is a small price to pay for tons
of optimization.
Christian.
On 11-Feb-09, at 13:29 , Howard Lewis Ship wrote:
> Just thought of a metaphor: think of all the wires on the back of you
> TV/Stereo stack ... the page acts like receiver, which internally
> connects all the components (TV, VCR, DVD, Wii) together. The result
> is a star-shaped graph, rather than a tesselation (i.e., imagine all
> the wires if every piece had to have a cable to connect it to every
> other piece!)
>
> On Wed, Feb 11, 2009 at 10:27 AM, Howard Lewis Ship
> <hl...@gmail.com> wrote:
>> I think of the page (really component) class as the "faciliator",
>> between components in the template.
>>
>> Also note that the type safety issue goes beyond performance; it's
>> also the gateway to optimizations and other features that rely on
>> type
>> and annotations. A var: may change its type at different times, and
>> will usually be null, making it hard to analyze statically. We could
>> add an annotation in the Java code to pin down the type of the var:
>> ... but then its easier to use @Property. I use @Property all over
>> the place, I don't think I use var: very often at all. The only
>> situation that would make sense would be if I was iterating some
>> objects and had a component to, for example, display the object
>> properties.
>>
>> On Wed, Feb 11, 2009 at 3:15 AM, Thiago H. de Paula Figueiredo
>> <th...@gmail.com> wrote:
>>> On Wed, Feb 11, 2009 at 12:54 AM, Christian Edward Gruber
>>> <cg...@israfil.net> wrote:
>>>> Hey Howard et. al.
>>>
>>> Hi!
>>>
>>>> <ol t:type="loop" t:source="listItems"
>>>> t:value="${var:(com.foo.bar.blah.MyObject)listItem}">
>>>> <li>${var:listItem.name}</li>
>>>> </ol>
>>>
>>> Notice you end up writing more code than you would using a @Property
>>> and it is way more fragile, as you would need to provide a fully
>>> qualified class name without IDE autocompletion and it is not
>>> refactoring-safe. I don't think it is a good idea.
>>>
>>>> In other words, it would explicitly provide a cast-like syntax to
>>>> allow the
>>>> bytecode manipulation to be instructed with the type. Now, I'm
>>>> not 100%
>>>> sure I think this is better than adding a single @Property
>>>> private MyObject
>>>> listItem in the code, but because this is truly a local variable
>>>> for this
>>>> iteration, it seems like having an instance variable is not
>>>> appropriate for
>>>> the purpose.
>>>
>>> If you think that the page class and the template are just to
>>> different sides of the same thing (the page) and that the template
>>> is
>>> not code, just a text template, having an instance variable is
>>> appropriate. :)
>>>
>>> --
>>> Thiago
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
Christian Edward Gruber
christianedwardgruber@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: local: in loops and strongly typed objects.
Posted by Howard Lewis Ship <hl...@gmail.com>.
Just thought of a metaphor: think of all the wires on the back of you
TV/Stereo stack ... the page acts like receiver, which internally
connects all the components (TV, VCR, DVD, Wii) together. The result
is a star-shaped graph, rather than a tesselation (i.e., imagine all
the wires if every piece had to have a cable to connect it to every
other piece!)
On Wed, Feb 11, 2009 at 10:27 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I think of the page (really component) class as the "faciliator",
> between components in the template.
>
> Also note that the type safety issue goes beyond performance; it's
> also the gateway to optimizations and other features that rely on type
> and annotations. A var: may change its type at different times, and
> will usually be null, making it hard to analyze statically. We could
> add an annotation in the Java code to pin down the type of the var:
> ... but then its easier to use @Property. I use @Property all over
> the place, I don't think I use var: very often at all. The only
> situation that would make sense would be if I was iterating some
> objects and had a component to, for example, display the object
> properties.
>
> On Wed, Feb 11, 2009 at 3:15 AM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>> On Wed, Feb 11, 2009 at 12:54 AM, Christian Edward Gruber
>> <cg...@israfil.net> wrote:
>>> Hey Howard et. al.
>>
>> Hi!
>>
>>> <ol t:type="loop" t:source="listItems"
>>> t:value="${var:(com.foo.bar.blah.MyObject)listItem}">
>>> <li>${var:listItem.name}</li>
>>> </ol>
>>
>> Notice you end up writing more code than you would using a @Property
>> and it is way more fragile, as you would need to provide a fully
>> qualified class name without IDE autocompletion and it is not
>> refactoring-safe. I don't think it is a good idea.
>>
>>> In other words, it would explicitly provide a cast-like syntax to allow the
>>> bytecode manipulation to be instructed with the type. Now, I'm not 100%
>>> sure I think this is better than adding a single @Property private MyObject
>>> listItem in the code, but because this is truly a local variable for this
>>> iteration, it seems like having an instance variable is not appropriate for
>>> the purpose.
>>
>> If you think that the page class and the template are just to
>> different sides of the same thing (the page) and that the template is
>> not code, just a text template, having an instance variable is
>> appropriate. :)
>>
>> --
>> Thiago
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: local: in loops and strongly typed objects.
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think of the page (really component) class as the "faciliator",
between components in the template.
Also note that the type safety issue goes beyond performance; it's
also the gateway to optimizations and other features that rely on type
and annotations. A var: may change its type at different times, and
will usually be null, making it hard to analyze statically. We could
add an annotation in the Java code to pin down the type of the var:
... but then its easier to use @Property. I use @Property all over
the place, I don't think I use var: very often at all. The only
situation that would make sense would be if I was iterating some
objects and had a component to, for example, display the object
properties.
On Wed, Feb 11, 2009 at 3:15 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Wed, Feb 11, 2009 at 12:54 AM, Christian Edward Gruber
> <cg...@israfil.net> wrote:
>> Hey Howard et. al.
>
> Hi!
>
>> <ol t:type="loop" t:source="listItems"
>> t:value="${var:(com.foo.bar.blah.MyObject)listItem}">
>> <li>${var:listItem.name}</li>
>> </ol>
>
> Notice you end up writing more code than you would using a @Property
> and it is way more fragile, as you would need to provide a fully
> qualified class name without IDE autocompletion and it is not
> refactoring-safe. I don't think it is a good idea.
>
>> In other words, it would explicitly provide a cast-like syntax to allow the
>> bytecode manipulation to be instructed with the type. Now, I'm not 100%
>> sure I think this is better than adding a single @Property private MyObject
>> listItem in the code, but because this is truly a local variable for this
>> iteration, it seems like having an instance variable is not appropriate for
>> the purpose.
>
> If you think that the page class and the template are just to
> different sides of the same thing (the page) and that the template is
> not code, just a text template, having an instance variable is
> appropriate. :)
>
> --
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: local: in loops and strongly typed objects.
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, Feb 11, 2009 at 12:54 AM, Christian Edward Gruber
<cg...@israfil.net> wrote:
> Hey Howard et. al.
Hi!
> <ol t:type="loop" t:source="listItems"
> t:value="${var:(com.foo.bar.blah.MyObject)listItem}">
> <li>${var:listItem.name}</li>
> </ol>
Notice you end up writing more code than you would using a @Property
and it is way more fragile, as you would need to provide a fully
qualified class name without IDE autocompletion and it is not
refactoring-safe. I don't think it is a good idea.
> In other words, it would explicitly provide a cast-like syntax to allow the
> bytecode manipulation to be instructed with the type. Now, I'm not 100%
> sure I think this is better than adding a single @Property private MyObject
> listItem in the code, but because this is truly a local variable for this
> iteration, it seems like having an instance variable is not appropriate for
> the purpose.
If you think that the page class and the template are just to
different sides of the same thing (the page) and that the template is
not code, just a text template, having an instance variable is
appropriate. :)
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: var: in loops and strongly typed objects.
Posted by Christian Edward Gruber <cg...@israfil.net>.
Crap, I meant var: in the subject.
Christian
On 10-Feb-09, at 21:54 , Christian Edward Gruber wrote:
> Hey Howard et. al.
>
> I was thinking about the var prefix in loops which allow for
> scalars to be held without having to create a property on the
> component. I was wondering about an alternative. I recognize that
> this mechanism doesn't use reflection, so cannot dynamically
> determine the type of the object, hence the limitation. But I
> wonder if a simple syntax change to allow type declaration would be
> suitable, such that the component could determine type at compile
> time. What I'm thinking would look something like:
>
> <ol t:type="loop" t:source="listItems" t:value="${var:
> (com.foo.bar.blah.MyObject)listItem}">
> <li>${var:listItem.name}</li>
> </ol>
>
> In other words, it would explicitly provide a cast-like syntax to
> allow the bytecode manipulation to be instructed with the type.
> Now, I'm not 100% sure I think this is better than adding a single
> @Property private MyObject listItem in the code, but because this is
> truly a local variable for this iteration, it seems like having an
> instance variable is not appropriate for the purpose. Also, I'm not
> sure about whether such instance variables end up on the heap, since
> they aren't created and destroyed on the call stack as are local
> variables. (Mind you, I'm not clear on how the bytecode is
> manipulated, so it could be that your pre-processing just creates an
> instance variable and it's all the same.) I admit part of this is
> an aesthetic choice, and I'm having real problems deciding which is
> more appropriate.
>
> It would be nice if you could get any type information from
> listItems, but Java's generics are meaningless out at runtime, and
> even then, it'd be runtime, not compile-time information you got
> back, so we're back to reflection. God I miss informal protocols
> and selector-based messaging in Objective-C... <sigh> If only
> Javasoft had listened when all us NeXTSTEPers bitched and complained
> about its absence...
>
> Anyway, I'm just putting it out there for comment. Essentially
> extending the var: binding's format with optional cast-alike syntax.
>
> cheers,
> Christian.
>
> Christian E. Gruber - President / Senior Consultant
> Isráfíl Consulting Services Corporation
> email: cgruber@israfil.net
> mobile: +1 (289) 221-9839
> web: http://www.israfil.net/
> "...keenness of understanding is due to keenness of vision."
>
>
>
>
>
>
>
Christian E. Gruber - President / Senior Consultant
Isráfíl Consulting Services Corporation
email: cgruber@israfil.net
mobile: +1 (289) 221-9839
web: http://www.israfil.net/
"...keenness of understanding is due to keenness of vision."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org