Why ctor? and why not "constructor"? about eo

[mdbs99]

@pa9ey maybe create/destroy ?

[mdbs99]

@stain please, no underscore! :)

[nqafield]

@yegor256 construct/destroy?

I know that the constructor and destructor are "special" methods in a sense and are called implicitly, but why name them differently than other methods? Methods are normally named as commands or verbs. You wouldn't say file.reader().

[stain]

Agree, I have never liked "ctor" (C Tor), are there other Tors as well then, "dtor" ? (Detour) If "constructor" is deemed too long (not my view), then perhaps "new" like in Ruby?

…

On 1 Dec 2016 10:07 am, "MadridianFox" ***@***.***> wrote: 👍 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPd5WU-0mw0J3ISX-Xz7pdUtQ8kfifxks5rDpwGgaJpZM4LAtbv> .

[nqafield]

@yegor256 How about this? (^; http://poll.lab.io/G5h11XOB__BL8YbksgxErw

[Tertioptus]

Like myself, I think there are a few non-contributors, so I'm not sure we should have an equal vote.

I propose that the Republic of EO vote for their top 3 favorite contributors to the project. And those three will vote to make the final decision. Their work and insight are already on display.

A periodical election wouldn't be bad either, to encourage leadership, responsibility, engagement which should lead to progress and quality, and not an abandoned project.

[yegor256]

My main priority is to make these creatures (ctor and dtor) obviously different from methods. That's why I don't really like create/destroy and other English words. That's why ctor/dtor is a good option for me, as well as +/- (even though semantically they are not really a good fit). See the point?

[stain]

Sorry, two weeks ago was a busy period for me and I missed #29 - it can be hard to keep track!

Let's have a alternative vote poll instead of changing it back and forward :)

[stain]

I think we want to keep the "object forking" like author("a",1) -- that might make it easier to support functions as objects or "constructors" that return an object with slightly different types than the original.

Perhaps when declaring this should be a special method name call() or something? Python has __call__() for this purpose (handle function call), but also __new__ (make object of this class) and __init__ (initialize self after it has been made). We hopefully won't need as many!

[nqafield]

@mdbs99 Yep. Even better.

[Tertioptus]

@pa9ey Yes! Thus construct and destruct are better than constructor and destructor. Yet, colloquially, create and destroy are more palatable. So I'm all in for create and destory. I think David West of Object Thinking would agree.

[Tertioptus]

@mdbs99

"release" actually makes more sense. "create" and "release". But not sure if that is too restrictive. It seems this language should be interpreter agnostic, such that we could port it to a platform that does not manage memory. Which begs the question, is "memory management" essential to declarative programming. Maybe I'm getting to far in the weeds.

[stain]

+1 to create/destroy :-) Also like the Object Pascal reference. In Java normally the finalise() is protected rather than public (it would only be called from the GC), but in EO all methods are public. Would it therefore be possible to call destroy() on an object, even if other objects still reference it? Presumably create/destroy are the two only two methods that are allowed to mutate an EO; but I think destroy() should be idempotent, multiple calls would be OK. That is, after a first destroy(), field references are freed (possible calling their destroy through GC or ref count) After this the object is "dead", every method call will throw an DestroyedObjectException, except destroy() which would then be a no-op. On 3 Dec 2016 2:38 pm, "Marcos Douglas B. Santos" <[email protected]> wrote: @Tertioptus <https://github.com/Tertioptus> it will not be mandatory to call the destructor directly, only if you want. About "create/release" vs "create/destroy", I choose the last one. If everybody likes "release", so my vote would be "new/release". — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPd5fWM_K7t5i2jIUOFhTC6fCyMyPdAks5rEX6HgaJpZM4LAtbv> .

[Tertioptus]

Okay then, could we just internationalize the language itself, such that nominally the keywords are concept-driven. For all I care, the keywords could all be in abbreviated Latin, as long as my IDE can render it to an American-English set for me.

brainstorming babble:
Even the Type level EO docs could contain a has for like translations, just in case someone wrote the code in Russian.

As longs as class names or nouns, and method names are verbs.

[alexpanov]

Thank you. I wanted to raise the same issue.
Keywords must be words first, keys second

[aravindps]

I agree!

[MadridianFox]

👍

[mdbs99]

I agree.
When I've started the #29 was about not use "same name of Type for constructors" and not use "~destructor C++ style".

But where were you who didn't vote?
Well, maybe we can change this now.

[alexpanov]

It's just an early draft. Many changes is something that one would only expect at this stage.

[yegor256]

@Tertioptus for me constructor just looks too long, that's why I was in favor of ctor in #29. How about before/after?

[moriline]

I think that keyword "new" for constructor is the best way.

[Lebedevsd]

@moriline why do we need new keyword, if instead of it we could directly call ctor?

why do you think that Author.new("a", 1) is better than author("a",1)?

[moriline]

@Lebedevsd Because "new" keyword(and as a word) means "new object" - this is exactly action what we do with/on type. For example:

Author.new("a", 1)

I order TYPE create NEW object with PARAMS.
"new" - constructor/action which we use on type of Author

Author author = Author.new("a", 1){
	String .name
	int .age
	new(String name, int age){
	    .name = name
	    .age = age
	}
	String name(){
	    return .name
	}
	
	int age(){
	    return .age
	}
}

There we are define and assign object of Author type.

[mdbs99]

@moriline I like the idea of using new too, but what happens with destructor, which name use if we choose new for constructor?

I order TYPE create NEW object with PARAMS.
"new" - constructor/action which we use on type of Autho

But we can't implement more than one type?

[mdbs99]

@yegor256 maybe we can use new for constructors and died for destructors. Both are short.

[mdbs99]

@pa9ey I was inspired by Object Pascal (OP).
However, OP has two keywords for constructors and destructors, ie, constructor and destructor. But they have names too. These names, by convention, are Create and Destroy.

constructor Create(Foo: Integer);
destructor Destroy;

[Tertioptus]

Would giving a Type the ability to "create" and "destroy" objects of it's specification, would that compromise the existence of objects that have public "create" or "destroy" behaviors.

[moriline]

@mdbs99 What about this?

Book book1 = Book.new("a", "1234"){
	String .title
	String .isbn
	new(String title, String isbn){
		.title = title
		.isbn = isbn
	}
	
	new(String title){
		new(title, "1111")
	}
        die(){
	}
}

If we are using destructor maybe die ?

[NikoGJ]

I agree in favor of making a constructor as a method/message
The same goes for desctructor but why would you want to destruct objects ? (except for technical implementation reasons)?

[mdbs99]

@moriline I said die too, but I prefer create and destroy now.

[mdbs99]

@NikoGJ

...why would you want to destruct objects ? (except for technical implementation reasons)?

If you want that GC — or ref-counting, whatever — release the object right now, you call the destructor.

[mdbs99]

@Tertioptus it will not be mandatory to call the destructor directly, only if you want.

About "create/release" vs "create/destroy", I choose the last one.
If everybody likes "release", so my vote would be "new/release".

[yegor256]

How about up/down?

[yegor256]

How about +/-?

[yegor256]

Do we need an open vote here? :)

[Hronom]

@yegor256 definitely need a vote if you dont creating language only for yourself...

Well newest IDE have autocompeltition, so I'm not worried about long names like: constructor/destructor, create/destroy

[sergiofigueras]

Hello guys :),

I'm coming just now for that discussion, but lets try to add something.

So, I dont see that a simple board vote will be enough for us, since the problem is not the voting itself, but our arguments to conclude a good approach. Also, I think that is a very special topic where we can't rely on a election for it.

use of CTor and DTor -> ok, it is nice. But as @alexpanov said, we should have keys as last options. It could be an alias for "constructor and destructor", for short. But it is not necessary to be a formal replacement for "Constructor and Destructor".
Constructor and Destructor -> nice too. Its a well established convention and honestly it expresses the correct idea of it.
Before and After -> it have other meanings in other languages and frameworks.
up / down -> doesnt see that it bring us a real value, its quite hard to understand the point of it.

• / - -> how operators overloading will be treated in EO? Can we do a sum of two different objects? Ex User.new("a") + Group.new("b")? And if I want to overload this "+" operator inside two different classes?

I think that our main concerns on it should be:
1 - use words first, keys only if it is necessary
2 - Usage of words that are not used in different languages with different approaches (like Before and After).

So, I would suggest to use Constructors and Destructors formally and CTors and DTors just as good nicknames and see what happens in the meanwhile. :)

[nqafield]

@sergiofigueras I do actually kind of agree. We could do with collecting the best arguments together for each proposed case. But then eventually we would still have to vote. (Unless Yegor vetos it, which I wouldn't particularly mind.)

But all of that is quite a long-winded process. I wouldn't mind having a quick vote for now and then going with something for a bit until we make a proper decision.

[yegor256]

@pa9ey I voted :)

[ixmanuel]

I think either "constructor" and "new" should be removed from EO, because it is a legacy concept. I don't see the "new" operator in the proposal, but the constructor is there. Therefore, I don't know what was the underlying concept that supports this decision, but I think that it is not consistent: new-constructor came from the same kind of thinking (thinking in terms of how computers work).

If we think that objects are on a stage, they appear as players that interact with each other, but they do not need to be born in each scene. They only need to appear on the scenes that are required.

These actors also require resources, e.g., clothing, tools, that already exist but they don't need to create their clothes each time that they come on the scene. Also, if both players need to collaborate to perform as a giant, they don't born again in order to form the structure.

Maybe "init" can resolve it.

[Tertioptus]

Borrowing your scenario, I believe that the constructor is the parameter interface to which the director interacts with, and the method parameters are the interface for the other actors. Such that during boot strapping of the app, the monolithic global application entity creates all of the objects, composing them via constructors. Post-creation, the objects interact(communicate) with each other via method parameters.

[nqafield]

@ixmanuel I agree that they don't need to be "born" each time. But, if we must use the stage production analogy, there is often a "cast list" at the start of the play. They must at least be described. The "Dramatis personæ", the "actors", are introduced. Are you just arguing about names?

How do you describe what an object is? What it encapsulates? With a special method called init?

Is that all you mean?

[stain]

Well, if EO objects are truly immutable, and constructors can't do any work (beyond constructing), then it should be a runtime implementation detail if they are created once and kept around for subsequent constructor calls (e.g. memorisation pattern ), always created fresh on demand (like java's new keyword), or a hybrid of these (soft references in cache). Perhaps what it comes down to for EO semantics is: * Does a second, identical constructor call always create a "different" object? (How can you tell?) * Can a constructor choose which object it returns, or is "this" always made/retrieved under the hood? And perhaps: * Can a object be uniquely identified using all and only all of its primary constructor arguments? (e.g. is the constructor functional or can it have side effects?)

…

On 15 May 2017 10:51 pm, "John Page" ***@***.***> wrote: @ixmanuel <https://github.com/ixmanuel> I agree that they don't need to be "born" each time. But, if we must use the stage production analogy, there is often a "cast list" at the start of the play. They must at least be described. The "Dramatis personæ", the "actors", are introduced. Are you just arguing about names? How do you describe what an object is? What it encapsulates? With a special method called init? Is that all you mean? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPd5b3VRKPxAMAGXD13blEwJv9cwkg4ks5r6MjbgaJpZM4LAtbv> .

[stain]

Btw, Python had *two* constructors:

…

__init__(self, *args, **kwargs) -- similar to in java constructor, "self" already exists but has no fields set yet.

__new__(cls, *args, **kwargs) -- default implementation in object.__new__ will allocate an empty object of the given class cls as "self" with the arguments to the __init__ constructor. Normally people only define a __init__. Overriding __new__ in Python allows you to "mess around" e.g. rewrite which (sub)class to instantiate or return a different (e.g. cached) "self". I don't think EO's philosophy of would be compatible with such "hacking enablers" - but this could of be an option for how EO constructors are implemented under the hood on JVM.

On 16 May 2017 5:26 pm, "Stian Soiland-Reyes" ***@***.***> wrote: Well, if EO objects are truly immutable, and constructors can't do any work (beyond constructing), then it should be a runtime implementation detail if they are created once and kept around for subsequent constructor calls (e.g. memorisation pattern ), always created fresh on demand (like java's new keyword), or a hybrid of these (soft references in cache). Perhaps what it comes down to for EO semantics is: * Does a second, identical constructor call always create a "different" object? (How can you tell?) * Can a constructor choose which object it returns, or is "this" always made/retrieved under the hood? And perhaps: * Can a object be uniquely identified using all and only all of its primary constructor arguments? (e.g. is the constructor functional or can it have side effects?) On 15 May 2017 10:51 pm, "John Page" ***@***.***> wrote: > @ixmanuel <https://github.com/ixmanuel> I agree that they don't need to > be "born" each time. But, if we must use the stage production analogy, > there is often a "cast list" at the start of the play. They must at least > be described. The "Dramatis personæ", the "actors", are introduced. Are you > just arguing about names? > > How do you describe what an object is? What it encapsulates? With a > special method called init? > > Is that all you mean? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#49 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AAPd5b3VRKPxAMAGXD13blEwJv9cwkg4ks5r6MjbgaJpZM4LAtbv> > . >

[ixmanuel]

@Tertioptus
Yes, what we currently name as a constructor, is an interface and the place where initialization occurs, that is, the beginning of an act (beginning could be a good name but is not different from init that is short). With this reasoning we could try other words: input, require, use, collaboration. The parameters come from the mathematical domain and are certainly inputs to the function. In our case, they are also inputs or collaborators.

@pa9ey
Yes, it is only about naming. But naming accordingly with the "EO" principles as @stain described:

if EO objects are truly immutable, and constructors can't do any
work (beyond constructing), then it should be a runtime implementation
detail

[ixmanuel]

@yegor256 has proposed "ctor" and "dtor", how do you see? "init" and "free".

[yegor256]

@Tertioptus I'm closing, since EO doesn't have constructors anymore