Draft SIP: From constructors to factories: Uniform treatment of object creation

[David MacIver]

Summary: Make it easy to switch from constructors to factories after
the fact by adding a mechanism where "new Foo(stuff)" can translate to
an invocation of a user defined method on the companion object.

http://www.drmaciver.com/factories-sip.xhtml

[Stepan Koltsov-2]

Why not just call apply method of companion object, without "new"?

S.

On Sat, Mar 14, 2009 at 17:05, David MacIver <david.maciver@...> wrote:
> Summary: Make it easy to switch from constructors to factories after
> the fact by adding a mechanism where "new Foo(stuff)" can translate to
> an invocation of a user defined method on the companion object.
>
> http://www.drmaciver.com/factories-sip.xhtml

[David MacIver]

A couple reasons:

- There is a distinct usage difference between apply and new in many
classes which have both.
- That doesn't achieve the goal of making it easy to move code which
is already using new to factory methods. If your intent is "no one
should ever use new" then that means everyone basically has to create
an additional factory methods for all their classes. People aren't
doing that now, and I don't see any reason to force them to do it.
- That doesn't achieve the goal of making this work properly with arrays.

On Sat, Mar 14, 2009 at 2:53 PM, Stepan Koltsov
<stepan.koltsov@...> wrote:

> Why not just call apply method of companion object, without "new"?
>
> S.
>
> On Sat, Mar 14, 2009 at 17:05, David MacIver <david.maciver@...> wrote:
>> Summary: Make it easy to switch from constructors to factories after
>> the fact by adding a mechanism where "new Foo(stuff)" can translate to
>> an invocation of a user defined method on the companion object.
>>
>> http://www.drmaciver.com/factories-sip.xhtml
>

[Ben Hutchison-2]

David MacIver wrote:
> Summary: Make it easy to switch from constructors to factories after
> the fact by adding a mechanism where "new Foo(stuff)" can translate to
> an invocation of a user defined method on the companion object.
>
> http://www.drmaciver.com/factories-sip.xhtml
>  
Generally, I like the idea of being able to switch from new Foo() to
Foo.new().

I have a question about your SIP. It seems that you propose that, when
the compiler encounters new Foo(x, y), if and only if c'tor signature
Foo(x, y) is not defined does it look for factory method Foo.new(x, y).

Presumably you considered the alterative that it looks for Foo.new(x, y)
first, then if not found, new Foo(x, y)? This would allow overriding
c'tors with a factory without removing the affected c'tor. Why do you
prefer the former option?

-Ben

--

       

*Ben Hutchison
Senior Developer
* Level 2 476 St Kilda Road Melbourne VIC 3004
T 613 8807 5252 | F 613 8807 5203 | M 0423 879 534 |
www.ibsglobalweb.com <http://www.ibsglobalweb.com/>

[David MacIver]

2009/3/23 Ben Hutchison <benh@...>:

> David MacIver wrote:
>>
>> Summary: Make it easy to switch from constructors to factories after
>> the fact by adding a mechanism where "new Foo(stuff)" can translate to
>> an invocation of a user defined method on the companion object.
>>
>> http://www.drmaciver.com/factories-sip.xhtml
>>
>
> Generally, I like the idea of being able to switch from new Foo() to
> Foo.new().
>
> I have a question about your SIP. It seems that you propose that, when the
> compiler encounters new Foo(x, y), if and only if c'tor signature Foo(x, y)
> is not defined does it look for factory method Foo.new(x, y).
>
> Presumably you considered the alterative that it looks for Foo.new(x, y)
> first, then if not found, new Foo(x, y)? This would allow overriding c'tors
> with a factory without removing the affected c'tor. Why do you prefer the
> former option?

Hm. That's a good question.

Offhand I can't think of a reason (minor boring quibbles about
backwards compatibility in edge cases aside). Let me have a think
about that and I'll get back to you.

[Raoul Duke]

>> Summary: Make it easy to switch from constructors to factories after
>> the fact by adding a mechanism where "new Foo(stuff)" can translate to
>> an invocation of a user defined method on the companion object.

could we instead just try to do away with 'new' pretty please perhaps?

[Jorge Ortiz-3]

This sounds dangerously close to some dangerous monkey-patching.

  package java.lang

  object String {
    def new() = ... // I'm in ur compiler, hackin' ur stringz
  }

Maybe String is a bad example because you rarely use "new String" explicitly, but you get the idea.

Also, I think this lends itself to more WTFs/minute (http://www.osnews.com/story/19266/WTFs_m) for people unfamiliar with the feature.

Consider:

"Someone is calling this constructor, but I don't see it defined anywhere. WTF?"

vs.

"I just added a new constructor to this class, but my code is mysteriously doing something else instead. WTF? WTF!"

The former might lead me to seek out someone more knowledgeable with Scala, while the latter might lead me to bang at the code for three hours in an attempt to figure it out.

--j

On Mon, Mar 23, 2009 at 4:09 PM, Ben Hutchison <benh@...> wrote:

David MacIver wrote:

Summary: Make it easy to switch from constructors to factories after
the fact by adding a mechanism where "new Foo(stuff)" can translate to
an invocation of a user defined method on the companion object.

http://www.drmaciver.com/factories-sip.xhtml
 

Generally, I like the idea of being able to switch from new Foo() to Foo.new().

I have a question about your SIP. It seems that you propose that, when the compiler encounters new Foo(x, y), if and only if c'tor signature Foo(x, y) is not defined does it look for factory method Foo.new(x, y).

Presumably you considered the alterative that it looks for Foo.new(x, y) first, then if not found, new Foo(x, y)? This would allow overriding c'tors with a factory without removing the affected c'tor. Why do you prefer the former option?

-Ben

--

       

*Ben Hutchison
Senior Developer
* Level 2 476 St Kilda Road Melbourne VIC 3004
T 613 8807 5252 | F 613 8807 5203 | M 0423 879 534 | www.ibsglobalweb.com <http://www.ibsglobalweb.com/>

[David MacIver]

2009/3/24 Jorge Ortiz <jorge.ortiz@...>:
> This sounds dangerously close to some dangerous monkey-patching.
>
>   package java.lang
>
>   object String {
>     def new() = ... // I'm in ur compiler, hackin' ur stringz
>   }

This doesn't work. It has to go on the companion object, which has to
be defined in the same file. It's not enough for the object to merely
have the same fully qualified name. Also the above simply gives a
compile error because the object is defined twice.

> Maybe String is a bad example because you rarely use "new String"
> explicitly, but you get the idea.
>
> Also, I think this lends itself to more WTFs/minute
> (http://www.osnews.com/story/19266/WTFs_m) for people unfamiliar with the
> feature.
>
> Consider:
>
> "Someone is calling this constructor, but I don't see it defined anywhere.
> WTF?"
>
> vs.
>
> "I just added a new constructor to this class, but my code is mysteriously
> doing something else instead. WTF? WTF!"
>
> The former might lead me to seek out someone more knowledgeable with Scala,
> while the latter might lead me to bang at the code for three hours in an
> attempt to figure it out.

Fair point. It's probably a bad idea. :-)

[Martin Odersky]

On Tue, Mar 24, 2009 at 1:16 AM, Raoul Duke <raould@...> wrote:
>>> Summary: Make it easy to switch from constructors to factories after
>>> the fact by adding a mechanism where "new Foo(stuff)" can translate to
>>> an invocation of a user defined method on the companion object.
>
> could we instead just try to do away with 'new' pretty please perhaps?
>
I also think that would be the nicer generalization. I have not
thought about this or the SIP too much recently. So I'm not quite sure
what to think of it.

Cheers

 -- Martin

[David MacIver]

2009/4/2 martin odersky <martin.odersky@...>:

> On Tue, Mar 24, 2009 at 1:16 AM, Raoul Duke <raould@...> wrote:
>>>> Summary: Make it easy to switch from constructors to factories after
>>>> the fact by adding a mechanism where "new Foo(stuff)" can translate to
>>>> an invocation of a user defined method on the companion object.
>>
>> could we instead just try to do away with 'new' pretty please perhaps?
>>
> I also think that would be the nicer generalization. I have not
> thought about this or the SIP too much recently. So I'm not quite sure
> what to think of it.

I'd be totally ok with doing away with new in lieu of this SIP if
someone can come up with a decent proposal for doing so. :-)

[Alex Boisvert-3]

On Thu, Apr 2, 2009 at 2:38 PM, David MacIver <david.maciver@...> wrote:

2009/4/2 martin odersky <martin.odersky@...>:

> On Tue, Mar 24, 2009 at 1:16 AM, Raoul Duke <raould@...> wrote:
>>>> Summary: Make it easy to switch from constructors to factories after
>>>> the fact by adding a mechanism where "new Foo(stuff)" can translate to
>>>> an invocation of a user defined method on the companion object.
>>
>> could we instead just try to do away with 'new' pretty please perhaps?
>>
> I also think that would be the nicer generalization. I have not
> thought about this or the SIP too much recently. So I'm not quite sure
> what to think of it.

I'd be totally ok with doing away with new in lieu of this SIP if
someone can come up with a decent proposal for doing so. :-)

Gilad's musings on constructors/factories may be relevant (and also a mixed bag)
http://gbracha.blogspot.com/2007/08/object-initialization-and-construction.html

"Because an instance is created by sending a message to an object, and not by some special construct like a constructor invocation, we can replace the receiver of that message with any object that responds to that message. It can be another class (say, an implementation based on polar coordinates), or it can be a factory object that isn’t a class at all."

Structural typing to replace constructors?  I'd actually prefer something along the lines of having implicit factories in scope (with defaults to class constructors) and injecting implicits via your (rejected) import SIP.     One can always hope! ;)

alex

[Adriaan Moors-2]

I think it would be great to make companion objects more like (lightweight) meta-classes.

It would be cool if you could specify an abstract companion object together with an abstract class, so you know subclasses will have certain meta-members  (after all, a constructor is just a method sent to the class-object, i.e., the instance of the meta-class)

As a concrete illustration, we can already approximate this pattern:  (using quick implementation of monads as an example, many more applications exist of course..) 

trait Monads {

   trait Meta[M[X], T] {

      def unit: M[T] // a constructor with a domain-specific name...  (and a non-standard return type)

    }

   // unfortunate that this has to be a method (not stable,...)

   // pulling up the M, T type params has other downsides

   def Monad[M[X], T]: Meta[M, T] 

   class Monad[M[X], T] {

      def bind[U](f: T => M[U]): M[U]

   }

}

I'd like to write something like:

trait Monads {

   meta Monad[M[X], T] {

      def unit: M[T] // a constructor with a domain-specific name... (and a non-standard return type)

    }

   class Monad[M[X], T] {

      def bind[U](f: T => M[U]): M[U]

   }

   // cannot define class List[T] without meta List[T] (also, the inheritance in meta List must follow the one in class List)

   meta List[T] extends Monad[List, T] {

     def unit = List()

   }

   class List[T] extends Monad[List, T] {

     def bind[U](f: T => List[U]): List[U] = flatMap(f)

   }

}

anyway, I'm just dreaming here.. this is probably too crazy to ever really go into the language ;-)

adriaan

On Fri, Apr 3, 2009 at 2:04 AM, Alex Boisvert <boisvert@...> wrote:

On Thu, Apr 2, 2009 at 2:38 PM, David MacIver <david.maciver@...> wrote:

2009/4/2 martin odersky <martin.odersky@...>:

> On Tue, Mar 24, 2009 at 1:16 AM, Raoul Duke <raould@...> wrote:
>>>> Summary: Make it easy to switch from constructors to factories after
>>>> the fact by adding a mechanism where "new Foo(stuff)" can translate to
>>>> an invocation of a user defined method on the companion object.
>>
>> could we instead just try to do away with 'new' pretty please perhaps?
>>
> I also think that would be the nicer generalization. I have not
> thought about this or the SIP too much recently. So I'm not quite sure
> what to think of it.

I'd be totally ok with doing away with new in lieu of this SIP if
someone can come up with a decent proposal for doing so. :-)

Gilad's musings on constructors/factories may be relevant (and also a mixed bag)
http://gbracha.blogspot.com/2007/08/object-initialization-and-construction.html

"Because an instance is created by sending a message to an object, and not by some special construct like a constructor invocation, we can replace the receiver of that message with any object that responds to that message. It can be another class (say, an implementation based on polar coordinates), or it can be a factory object that isn’t a class at all."

Structural typing to replace constructors?  I'd actually prefer something along the lines of having implicit factories in scope (with defaults to class constructors) and injecting implicits via your (rejected) import SIP.     One can always hope! ;)

alex


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm for more information.

[jherber]

Personally, I'd like to see the form "new SomeClass(constructorParam)" eventually go away.  It is inconsistent with the syntax for sending messages.  Inconsistencies add to the complexity of the mental model of the language.

If "new" were not given special keyword treatment (or perhaps just syntactic sugar treatment for backwards compat.), it would be a "regular" message responder on the class definition.  This would also make it far game on the companion singleton object definition.

I'd really like to see examples of how this fits in with Martin's "Scalable Components" paper, specifically with Dependeny Injection as exemplified by Jonas excellent blog posting on that subject matter.

David MacIver wrote:

Summary: Make it easy to switch from constructors to factories after
the fact by adding a mechanism where "new Foo(stuff)" can translate to
an invocation of a user defined method on the companion object.

http://www.drmaciver.com/factories-sip.xhtml