--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojure-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
The main reason for the non-movement on your implementation specify is that the patch does far more than what Rich proposed
- which was that specify would be like reify but for single objects - this implies *cloning*.
If the patch had followed the original limited idea it would have likely been adopted already as an experimental feature.
specify & specify* appears to mutate the target object w/o cloning, this is OK for prototypes, but broken for instances defeating the whole point of the original idea as far as I can tell.
Applying the first patch produces a version of ClojureScript where I'm unable to confirm the mutating behavior of specify & specify* - there are many errors when trying to run the CLJS REPL.
To be fair, I had no Idea what Rich proposed, or what even you wanted to see in a design. I have had tried to scratch my own itch with a thing called extend-instance, which was supposed to modify the instance. Then you told me Rich had come up with a name for that: http://dev.clojure.org/jira/browse/CLJS-398
I then continued developing for my own needs with the specify name: http://dev.clojure.org/jira/browse/CLJS-414And I created a design page to allow others to review the design.
- which was that specify would be like reify but for single objects - this implies *cloning*.It certainly doesn't from a technical perspective. In fact the mutation of the original object is by design, to allow efficient specification of a list of 10000 json objects.
specify & specify* appears to mutate the target object w/o cloning, this is OK for prototypes, but broken for instances defeating the whole point of the original idea as far as I can tell.It might appear so from a design perspective, but it's actually the other way round:When cloning is an option, there is no issue at all, since you can control the prototype of objects you new yourself, hence give it whatever type you please.specify makes sense, as soon as you get a bunch of objects from a source, that transfers ownership to you, but doesn't allow you to control the prototype.One such example is the usage of JSONP, where objects are always created by eval.
Also it makes really good sense as the bottom of the protocol / type stack. As you might have noted, the patches substantially cleanup extend-type (the current bottom of cljs types), by having it specify the prototype.
Sorry I probably should have linked to the few places where Rich mentioned `specify` - the devnotes in the CLJS repo and the old thread about getting `reify` in to CLJS. I never moved forward with `specify` myself since I was able to implement a fairly efficient `reify` without it. I believe Rich suggested that with `specify` you could implement `reify`. He didn't mention `extend-type`, and in fact in the devnotes in the repo for `extend` it says "Maybe not?".
The question here is whether a powerful object mutation feature like this isn't better provided by an external library.
This seems at odds to the Clojure/ClojureScript ethos of keeping the cloning work out of the users hands.
Cleanup is nice but not a compelling reason to include or not include a language enhancement.
The question here is whether a powerful object mutation feature like this isn't better provided by an external library.An excellent point and if it could be done, I probably wouldn't even have opened a ticket (which I now know was the wrong way to start this anyway).Alas, any library needs a way to get from protocol methods to js methods.specify* is pretty much an api to access the builtin name mangling.In fact, I would be happy to just publish specify* and leave everything else to libs, since specify* is what I really need and use.
JSONP keeps the cloning out of the user's hand aswell. It's also Clojure's ethos that platform integration trumps cleanliness.Right now Clojurescript prevents objects that haven't originated from a Clojurescript constructor from interacting with protocols, even though it's technically possible.Cleanup is nice but not a compelling reason to include or not include a language enhancement.
At this point we really only should be discussing whether and in which form we want to make the functions public, that fell out by refactoring.
(because it's also clojure's ethos that the only person allowed allowed to write fns of more than 15 lines, is Rich Hickey ;-)You may notice, that my specify impl doesn't do anything "new". It's just the bit's and pieces, pulled out from the two page long extend-type *macro*:
Need and use for what? Your design page is sparse and I can imagine many other ways to do what you've done. For example, I find the explicit arities in specify* to be warty. I haven't seen any thought in 7 months on how this wart might be removed.
The design page mostly documents your *solution*. That's not what design pages are for.
But what about the likely common use case of wanting to clone + extend? Why not `specify` and `specify!`? Again I don't see much thought on this on the design page.
Tip toe around what? Do you think you'll offend anybody? :)
Yes it's quite gnarly but what does that have to with your actual feature proposal?
As such your patch is a minor enhancement plus a new bottom level macro that doesn't have nearly enough design work IMO.
A contribution that I would feel more positive about:* A separate enhancement patch that implements your nice bit of refactoring - no other change* A much more fleshed out design page - no patches