Comments on: MooTools 1.2.2 and the New MooTools More

By: aaron

aaron — Mon, 04 May 2009 05:54:01 +0000

@lordpx, could you open a ticket with details?

By: lordfpx

lordfpx — Sun, 03 May 2009 20:08:42 +0000

Hello

It's always good to see progress, unfortunatly, "scroller" is not working very good with this new version... it doesn't "stop" anymore here and on another page it's not working anymore and I don't know why. Uvumitextarea is not working anymore too, strange...

So I'm back to the previous release :-(.

By: aaron

aaron — Sat, 02 May 2009 03:34:58 +0000

@007 previously if you implemented an object over another one it would overwrite it entirely. If you did:

Animal.implement({ options: { says: 'meow'});

and Animal previously had an options object, in 1.2, options would be overwritten, not blended with this new property.

By: 007

007 — Sat, 02 May 2009 03:04:32 +0000

Another object-oriented feature we introduced is that now sub-objects are actually inherited Parent-to-Child ?

previous version(1.2.1) also implement that. what's the difference of the two version? thx

By: kamicane

kamicane — Fri, 01 May 2009 03:02:53 +0000

@jay:

you can test it

I assure you we did test it pretty extensively.

Again, if you have a bug to report, please do so in our ticketing system. I get it, you dont like how MooTools works, but there's nothing much I can do about it :)

By: jay

jay — Fri, 01 May 2009 02:48:22 +0000

@kamicane There’s a check in place to prevent that

I am sorry.I can't find the place for check that and prevent.

anyway,I absolutely invoke class.wrap twice when I invoke the function(setOptions).you can test it.

By: kamicane

kamicane — Fri, 01 May 2009 02:31:46 +0000

@jay:

well,I don’t agree with the process for Implements

I'm sad to hear that.

if I implement the Options class,the class function(setOptions) is wraped twice by Class.wrap

Obviously, that's not the case. There's a check in place to prevent that. If it actually did wrap it twice, everything would break up, and we would have definitely noticed.

If you have any ideas on how to improve further versions of Class, feel free to open up a ticket in lighthouse, or make a patch.

By: jay

jay — Fri, 01 May 2009 02:25:03 +0000

@kamicane : well,I don't agree with the process for Implements. for example,if I implement the Options class,the class function(setOptions) is wraped twice by Class.wrap. On another note,_hidden is not used. I just want to know the benefit of class.wrap for Implements.

case 'function':if (value._hidden) return this; proto[key] = Class.wrap(this, key, value);

By: kamicane

kamicane — Fri, 01 May 2009 01:17:20 +0000

@jay:

"is that a right way"

Yes.

debug will be very diffcult

No, as it's not any more difficult than debugging a function that calls another function.

it is very easy to cause memory leak.

No, as the usage of Function:bind doesnt cause memory leaks.

On another note, we always wrapped class functions, it was just a little more convoluted in previous versions.

By: jay

jay — Thu, 30 Apr 2009 08:14:10 +0000

every function is wraped by Class.wrap. is that a right way? 1.debug will be very diffcult 2,it is very easy to cause memory leak.

By: aaron

aaron — Tue, 28 Apr 2009 15:34:43 +0000

@131 You must realize that this is just the start. The -more collection of plugins are plugins that the MooTools developers have authored that we want to share. They aren’t like -core which is required - you can’t use MooTools without using -core. But everything in -more is optional, and this is just the first batch. Expect to see new functionality added often. -core updates every 6 to 8 months, but we hope to iterate -more every two or three weeks, adding one or two new plugins as we go along. Hopefully we’ll end up adding one you like at some point.

By: Ryan

Ryan — Tue, 28 Apr 2009 14:33:05 +0000

looks like great improvements.

@ksamdev if you don't like elements of More then you don't have to use them. plain and simple. Your comparisons of More being a framework itself is severely flawed. Use what you want and ditch the rest. That's why it's structured the way it is.

By: 131

131 — Tue, 28 Apr 2009 14:12:13 +0000

I'm sorry to say that, but i'm a little disapointed, i mostly agree with ksamdev, i like mootools because it provide only what i need (and a little 'more'), i regret a "true" namespacing/repository hadn't be set up to deal with 3rd modules. I prefer a lot insert dependencies for mt://ClientCide/Class/Class.Bind rather than seeing the "official" More heriting Application specific code, (forcing Localization is a real bad idea, for example) - A.N. that's still excellent work, that was never my point.

By: Mark Story

Mark Story — Tue, 28 Apr 2009 12:40:04 +0000

Great work guys and gals! I’m glad to see mootools more grow, the clientcide libraries were great but now with more eyes and hands working on them I’m sure they will get even better. Class.refactor is amazing stuff as well.

By: Jem

Jem — Tue, 28 Apr 2009 03:59:34 +0000

Great news!

Very excited about the new class changes! Thank you all for your hard work!