RE: Re: "proto" versus "newObject"

From: Paul Prescod

> Let's propose just for argument's that the main problem is 
> overlapping 
> namespaces and the only two cases that matter are call_ and 
> str_. In a 
> recent message I suggested a "conventional workaround" for 
> str_ that may 
> be acceptable.
> 
> Here's my proposal for fixing call_: just say outright that 
> prototypes 
> are not derived from using call_. Use a new method called new() or 
> "newObject()"
> 
> 	File.new()
> 	List.new(someobj)
> 
> Is that too ugly?
> 
> 	myfile = File.new("/tmp/foo.txt")
> 
> Another potential syntax is:
> 
> 	myfile = new File("/tmp/foo.txt")
> 
> I think that obj.new() is quite explicit and readable about what is 
> going on.

We used up a lot of messages deciding between Proto() and Proto.new()
about a month ago here on the list.  At that time the concern was about
using up the call_ so it wouldn't be available for other purposes, which
I guess is just another way of saying that the namespaces overlap.  I
argued for keeping the Python way and won.  The problem is that the
"Proto()" construction technique is so fundamental to Python and it is
not "broken".

Using the "new" keyword was ruled out quickly.

In my new two-tier class proposal we would have a different namespace
for the instance (Class) and the class (Class.class_).  So the call_()
method would not have a problem.  Let's assume for now that my class
proposal or someone else's will solve the problem.