new instantiation design alternatives

Caitlin Potter caitpotter88 at gmail.com
Mon Sep 15 22:02:52 PDT 2014


On Sep 15, 2014, at 9:58 PM, Alex Kocharin <alex at kocharin.ru> wrote:

>  
> What "controller instance" is, and why can't you add your own stuff after creating an object?

It’s an instance of an object, there’s nothing special here. We don’t add stuff after it’s created because it’s convenient for it to be there to begin with, that’s where it’s useful (and while it would be possible to re-add it if they returned a new value, we don’t because there’s no reason to ever support such crazy code). But as I said before, this is just an example of something which is basically impossible to accomplish with return values from a constructor.

Spending too much time focusing on that doesn’t really add much to the discussion, though.

>  
> The advantage of returning an arbitrary object is that constuctor controls exactly what it creates. If it needs to return an array instead of an object, inserting custom methods on it for example, it's possible. Without that ability it's not.

You could return a primitive or function, but then you may as well be using a factory rather than a constructor, and that would make a lot more sense for that behaviour. So for use cases which make sense, a constructor is always going to return an object — and at that point, returning a new object is basically just disallowing placement new.

> Also, it's about encapsulation. Whatever constructor is doing is it's own stuff, and external libraries shouldn't mess with it. Same thing as with private variables in C++ for example, they limit flexibility considerably, but people don't argue that they should be deprecated.

Well in the case of the example, I would argue that we’re not really violating encapsulation. You certainly could break encapsulation, but in this case we’re doing it because a developer specifically asked to have properties bound to an instance of their object, and the specific properties to populate, as well.

Anyways, as I said earlier, this is really just an example of how you can get something out of using this strategy, and why the flexibility of being able to return a custom value is not always a good thing (and why such behaviour really fits a factory pattern better).

But again, I’m not sure this adds a whole lot to the topic, it’s really just there as an example of how the behaviour you’re talking about can be harmful. It takes guarantees out of the system, for arguably no real gain, which can be complicated to accommodate (read: more complicated than it’s worth). Lets just agree to disagree for now, it’s not worth continuing this sub-topic =)

>  
> 16.09.2014, 05:10, "Caitlin Potter" <caitpotter88 at gmail.com>:
>> It’s just an example, but we recently changed Angular.js in such a way that we could pre-populate a controller instance (instantiated via user-specified constructor functions) with data before calling the constructor itself. This is a convenience, so that the data is readily available for the controller to use as soon as it begins its life.
>>  
>> Needless to say, returning an arbitrary value from the constructor doesn’t do what is expected, because the populated data isn’t re-configured for the newly returned value, and the return value is essentially ignored. It doesn’t have to work this way, but it does, and it would have been nice if returning values from constructors was never in the cards to begin with — similar to how it’s not possible in other languages. We essentially are using a version of placement new in JS, and it’s rather nice for providing these conveniences.
>>  
>> It’s fair to say we’re doing it wrong, but it’s hard to ignore the advantages/flexibility of it. What is the advantage of returning an arbitrary object from a constructor, other than being similar to JS as it is today?
>> 
>> On Sep 15, 2014, at 8:37 PM, Alex Kocharin <alex at kocharin.ru> wrote:
>> 
>>>  
>>>  
>>> 15.09.2014, 23:23, "Rick Waldron" <waldron.rick at gmail.com>:
>>>> 
>>>> 
>>>> On Mon, Sep 15, 2014 at 2:57 PM, Brendan Eich <brendan at mozilla.org> wrote:
>>>> Rick Waldron wrote:
>>>> The first is also objectionable because it breaks existing implicit return semantics.
>>>> Say what? Constructors can return a different object from `this`, that's just JS.
>>>>  
>>>> Yikes, I should've been more specific. Generally, it's considered an anti-pattern to write constructors that explicitly return an object to override `this`(for all the reasons you'd expect)—that's not to say that it isn't done or doesn't exist (and certainly I didn't mean to imply that it wasn't possible). Design that might rely on that pattern would conflict with widely accepted best practices. 
>>>>  
>>>  
>>> Writing constructors that override `this` is not an anti-pattern. It's an implementation detail that should not ever matter to any outside code.
>>>  
>>> If your code breaks because somebody returns another object from constructor, you're doing it wrong.
>>>  
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140916/dce707ce/attachment.html>


More information about the es-discuss mailing list