I hadn't considered that particular functional approach. When we started on
Mojo, we decided on using an OO style versus a functional one, as we guessed
that it would be more familiar to the bulk of our potential developers.
Certainly it was more familiar to everyone on the team.
Your example does look fine, although I don't like that I'd have to do that
local variable trick in every class declaration.
My comparison of clarity had nothing to do with functional vs. OO. It was
only a comparison of namespaced vs. prototypical access.
We do have the benefit of working in a controlled environment, although we'd
like to allow other JavaScript libraries be able to co-exist with Mojo as
much as possible. Once our SDK is out it will be interesting to see what's
needed to make that happen.
On Tue, Mar 10, 2009 at 11:48 AM, kangax <kan...@gmail.com> wrote:
>
> On Mar 10, 10:27 am, Rob Tsuk <robt...@gmail.com> wrote:
> [...]
> > One example is the bind() method on Function. Mojo requires application
> > developers to create a certain number of objects whose methods are likely
> to
> > be used as callbacks, and bind() is invaluable for establishing the
> "this'
> > keyword in those cases. It would not improve matters at all to have to
> call
> > Prototype.Function.bind(this.handleRequest, this) rather than
> > this.handleRequest.bind(this).
>
> You don't have to call it like that : )
> Properties can be aliased to local variables in closures. Local
> variables are cheap and closures are flexible.
>
> Does this really look/feel so bad?
>
> var Widget = Class.create((function(){
>
> var bind = Prototype.lang.bind;
>
> return {
> initialize: function(id) {
> this.element = $(id);
> this.init();
> },
> init: function()
> this.element.observe('click', bind(this.onClick, this));
> },
> onClick: function(){
> // ...
> }
> }
> })());
>
> I understand the ubiquity of `bind` and desire to access it directly
> on a function (which is why ES3.1 introduces native `bind`), but if we
> are talking about general use on the web (i.e. maximum compatibility),
> I don't see how the alternative approach makes code any less clear or
> any less pleasant to use. The only downside I see is that you have
> another variable (local to your "class") to watch out for.
>
> >
> > Even if there were an option to run Prototype in a namespace and have it
> not
> > extend native prototypes, I doubt we would enable it for Mojo. If we did,
>
> That's the beauty of developing for a controlled environment (please
> correct me if I'm wrong)
>
> > we'd have to make all the code in the framework avoid depending on the
> > prototypes and use the namespaces, and I don't the what that would do to
> > code clarity in the framework would be worth the theoretical
> compatibility.
>
> I think it's a myth that code clarity is being lost when moving from
> oo approach to a more functional one. You only need to change the way
> you approach things. It's good to remember that not relying on
> augmenting *native prototypes* still allows to take advantage of
> expressive prototypal nature of Javascript.
>
> --
> kangax
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
