Sorry - will correct that immediately. "Implements" doesn't exist on middleclass, but somehow I tend to write it here and there instead of "include". I was exposed to Java 7 years ago and I'm still suffering some after-effects.
leiradel wrote:Shouldn't you bump the version up to 2.0 since it's a backwards-incompatible release?
Good question. The answer is no - I use the middle one for backward-incompatible changes. Here are the rules I'm using lately:
The right number (x.x.1, x.x.2, etc) is for backwards-compatible changes, i.e. bugfixes.
The middle number (x.1.x, x.2.x, etc) is for backward-incompatible changes, such as this one.
The left number (1.x.x, 2.x.x, etc) is for complete rewrites; normally this would mean a change in the paradigm or something.
I have not followed this schema very strictly in the past, but it's the one I'm following in other projects now and it's easier for me to have a single set of rules.
But yeah, the middleclass-extras documentation is a little out of date (I think I remember MindState being mentioned somewhere... or was that in middleclass itself?)
kikto wrote:I was exposed to Java 7 years ago and I'm still suffering some after-effects.
BlackBulletIV wrote:But yeah, the middleclass-extras documentation is a little out of date (I think I remember MindState being mentioned somewhere... or was that in middleclass itself?)
Indeed, there was one I'm ashamed. I've corrected it.
I try to keep comments up-to-date, but it's so difficult!
In my defense, I must say that the specs, at least in the last months, have always been updated (they are actually a great tool for testing changes on middleclass and middleclass-extras)
Just took a look at specs, I didn't know they existed; that's some pretty thorough testing there (well, you are a Rubyist). I must get myself into the habit of unit testing sometime soon; I've been lazy (and paid the price) in the past.
This is a backwards-compatible version, so if 1.3 worked for you, this one should do just fine.
The changes:
Added a new method to Object called allocate. Allocate is called by new before calling initialize, and it creates an "uninitialized" instance. The "allocation" works exactly as before, but it is on a method instead of inside new. That simplifies certain mixin creation problems. Kudos to BlackBulletIV for helping me on realize and implement this.
Made a small change in the way the internal _classes variable was used. Now it should be slightly faster and consume slightly less memory.
Also made some specs for this.
Pending stuff:
I've to modify the implementation of some of the elements in middleclass-extras so that they use allocate. This will allow me to solve a couple problems - Indexable can't index inside initialize, and Callbacks overrides too much stuff. I hope to implement these over the weekend.
These changes should also be backwards-compatible, except that they solve the aforementioned problems.
kikito wrote:This is a backwards-compatible version
Not precisely. Problems will likely be caused if anyone was hacking around at the low level with the new method. In the case anyone was doing this, chances are you'll probably want to define the allocate method now.
BlackBulletIV wrote:Not precisely. Problems will likely be caused if anyone was hacking around at the low level with the new method. In the case anyone was doing this, chances are you'll probably want to define the allocate method now.
Not really. new does the same thing as before. It's just separated into two functions. If anyone re-defined it, it'll say redefined. If anyone used its returning values, they'll be the same. There's more ways to change it now, but the ones that existed before are left untouched.
No what I meant was, if someone redefined new, and then included something which redefined allocate, the thing which defined allocate wouldn't work at all. Whereas if both redefined allocate (assuming their redefinitions didn't have conflicting code), they'd both work.
By the way, I've issued a pull request with Indexable and Callbacks modified to redefine allocate.
You are right. If someone has a method called "allocate", then 1.4 would probably give trouble.
But the user base is so small that I unconsciously discarded that possibility.
I've made a quick review of the changes and send a comment. Today and tomorrow are going to be really hectic, so I might not be able to commit them until the weekend.
I'm ashamed. I've corrected it.
