in reply to Re5: Constructor/Factory Orthodoxy
in thread Constructor/Factory Orthodoxy

I find it almost comical that this one construct gives so many people angina. I agree that cloning is separate and different. To clone means to make identical. To make a new instance of something means just that: make a new one. So in my mind you can do both. Offer a clone method if you truly are going to make an exact copy of the referent; offer a new method that allows instances as referents if you want to allow someone to make a new one like them. In other words, I don't see the dual constructor as two distinct methods (new and clone) but rather as two ways of asking for a new instance. I don't see the great value in forcing the caller to create the class name each time. In my mind new one of this class and new one like this one I already have are basically the same thing that this one simple line in one place can deal with. I believe the only reason people get so uptight about it is that traditional OO languages don't allow or offer it. If we follow that line of thinking we also should require set names for constructors, no inheritence of constructors, and (according to most) no multiple inheritence.

Replies are listed 'Best First'.
Re7: Constructor/Factory Orthodoxy
by dragonchild (Archbishop) on Feb 27, 2003 at 14:21 UTC
    "new" means to make a completely new one. Cloning doesn't mean to make a new one. It means copy this one. The big difference is when the object has a list of other objects contained within it. What does clone mean in this case? Does A and B both point to the same list (shallow copy)? Does B have its own list, each with clones of those contained objects (deep copy)? It's not clear, and that's because a given application might want either behavior, or something completely different. When something isn't clear, it should be made clear. Making it clear, in my mind, involves different methods. Maybe they share a bunch of stuff under the hood, but that's a good thing. There should be different presentations for different actions, though.

    "That line", as you put it, removes the distinction between the two concepts. That's not so good. Also, if you asked most people who used it, they would have no idea why that line was there, what it was good for, and what behaviors it allowed/disallowed. That is what my angina is about. If you write a line, you should know what that line does.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

      Well, you were the one who thought that
      my $class = ref $this || $this;

      meant cloning. It wasn't suggested by the OP, nor is it suggested by most people using this construct. I fully agree that cloning is something you only should do in very specific cases (and you'd need the full cooperation of all classes in the inheritance tree). It's easier to fix your perception than all the code using it.

      However, I don't find that an argument against the quoted contruct. It only gets confusing because you assign a totally different meaning to the construct then the construct is. That doesn't make the construct wrong. The only thing that's wrong is your perception of it.

      Abigail