Ugg. This seems the wrong approach. IFF (if and only if) we can prove
that it "works" and works well enough to support our limited goals, I
see no reason not to use this capability to improve our APIs.
Performance is something we struggle with everywhere, but like a11y we
*cannot* allow it to become a reason to stop pushing the edges. We
*need* getters and setters...that FF and IE are on par w/ performance
for them says to me that we may be close enough to say "yes, and" as
opposed to "no, but".
Regards
On Apr 7, 2008, at 9:07 AM, Tom Trenka wrote:
> I think what I'm trying to say here is that it's fine for DojoX--but
> I'd
> really hate to see people start using it elsewhere in the project
> (like in
> Dijit) until it comes out of experimental nature. I can see a lot
> of people
> hopping onto something like this without really considering the
> performance
> consequences of the code--so I would like to see it be really
> carefully
> considered.
> regards,
> trt
>
> On Mon, Apr 7, 2008 at 10:28 AM, Wolfram Kriesing <
> wolfram.kriesing <at> gmail.com> wrote:
>
>> I understand the point perfectly.
>> Therefore I mean to really have it in a separate package which
>> clearly states the "experimental" state of it.
>>
>> May be something like dojof for dojofuture? :) or dojox.future.*
>> And everything in there might be awesome to use but clearly is
>> a feature that will be touched and is not the final call,
>> something like dojox^2 
>>
>> I mean we are playing very much on the bleeding edge and
>> that will not be the only thing that comes along and starts
>> this kind of discussion. I am for: dont deny, let it evolve.
>>
>> just thoughts
>>
>> Wolfram
>>
>>
>> On Mon, Apr 7, 2008 at 5:15 PM, Tom Trenka <ttrenka <at> gmail.com> wrote:
>>>
>>> On Mon, Apr 7, 2008 at 9:57 AM, Wolfram Kriesing
>>> <wolfram.kriesing <at> gmail.com> wrote:
>>>> I think the performance implication thing is only a temporary
>>>> thing,
>>>> and that can be handled by some big fat warning.
>>>> I mean dojo.query() kind functionality pushed the envelope
>>>> to make this go into browsers and really squeeze all performance
>>>> possible out of it. And this is the first step (or one of the
>>>> first)
>>>> people will come up with patches and improvements.
>>>> I'd say: get it rolling, it can only get better.
>>>>
>>>
>>> I would entirely disagree with you there; if there are fixed
>>> performance
>>> implications and we introduce this API into the project, we're stuck
>> with
>>> it, whether or not we're able to figure out some other hacks to
>>> make the
>>> performance better.
>>>
>>> What I would suggest for now, in the absence of performance
>>> numbers &
>>> investigated implications, is to make Observable private to the data
>> store
>>> that is using it, and to *not* plan on taking advantage of the
>>> concept
>>> elsewhere throughout the toolkit without some real performance
>>> data to
>>> support it.
>>>
>>> The more I think about this solution, the more I am concerned about
>> killing
>>> perf in the name of trying to get real getters and setters,
>>> particularly
>> in
>>> something like Dijit. A good portion of the point of the 0.9
>>> split was
>> to
>>> increase the performance as much as possible, and if this causes a
>> fairly
>>> major hit (particularly if it's under a monte carlo test
>>> situation) then
>>> we're right back into the "its slow" thing.
>>>
>>> regards,
>>> trt
>>>
>>>
>>>>
>>>> Wolfram
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Apr 7, 2008 at 4:36 PM, Jared Jurkiewicz
>>>> <jared.jurkiewicz <at> gmail.com> wrote:
>>>>> I second Trenka's comment about performance implications.
>>>>> Creating
>>>>> wrapper objects in IE seems very scary/performance inhibiting.
>> Isn't
>>>>> this effectively the same thing as the 'lettable' idea Alex was
>>>>> talking about some few weeks back?
>>>>>
>>>>> -- Jared
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 7, 2008 at 10:32 AM, Bill Keese <bill <at> dojotoolkit.org>
>>> wrote:
>>>>>> Kris Zyp wrote:
>>>>>>> Observable creates a new object (a
>>>>>>> vbscript) that "wraps" the original.
>>>>>>
>>>>>> Uh oh, so that means we would need to resurrect the
>> createWidget()
>>>>>> factory method?
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dojo-contributors mailing list
>>>>>> dojo-contributors <at> dojotoolkit.org
>>>>>> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>>>>>>
>>>>> _______________________________________________
>>>>> dojo-contributors mailing list
>>>>> dojo-contributors <at> dojotoolkit.org
>>>>> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cu
>>>>
>>>> Wolfram
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dojo-contributors mailing list
>>>> dojo-contributors <at> dojotoolkit.org
>>>> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>>>>
>>>
>>>
>>> _______________________________________________
>>> dojo-contributors mailing list
>>> dojo-contributors <at> dojotoolkit.org
>>> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>>>
>>>
>>
>>
>>
>> --
>> cu
>>
>> Wolfram
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors <at> dojotoolkit.org
>> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors <at> dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
--
Alex Russell
alex <at> sitepen.com A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
alex <at> dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
| 
