-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why ctor? and why not "constructor"? #49
Comments
Thank you. I wanted to raise the same issue. |
I agree! |
👍 |
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>
.
|
I agree. But where were you who didn't vote? |
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 :) |
It's just an early draft. Many changes is something that one would only expect at this stage. |
@Tertioptus for me |
I think that keyword "new" for constructor is the best way. |
@moriline why do we need new keyword, if instead of it we could directly call ctor? why do you think that |
@Lebedevsd Because "new" keyword(and as a word) means "new object" - this is exactly action what we do with/on type. For example:
I order TYPE create NEW object with PARAMS.
There we are define and assign object of Author type. |
@moriline I like the idea of using
But we can't implement more than one type? |
@yegor256 maybe we can use |
I think we want to keep the "object forking" like Perhaps when declaring this should be a special method name |
@stain please, no underscore! :) |
@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 |
@pa9ey maybe create/destroy ? |
@mdbs99 Yep. Even better. |
@pa9ey I was inspired by Object Pascal (OP).
|
@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. |
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. |
@mdbs99 What about this?
If we are using destructor maybe |
I agree in favor of making a constructor as a method/message |
If you want that GC — or ref-counting, whatever — release the object right now, you call the destructor. |
"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. |
@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. |
+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" <notifications@github.com> 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>
.
|
How about |
How about |
Do we need an open vote here? :) |
@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: |
@yegor256 How about this? (^; http://poll.lab.io/G5h11XOB__BL8YbksgxErw |
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".
I think that our main concerns on it should be: 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. :) |
@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. |
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. |
My main priority is to make these creatures (ctor and dtor) obviously different from methods. That's why I don't really like |
@pa9ey I voted :) |
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: As longs as class names or nouns, and method names are verbs. |
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. |
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. |
@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 Is that all you mean? |
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>
.
|
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>
> .
>
|
@Tertioptus @pa9ey
|
@yegor256 has proposed "ctor" and "dtor", how do you see? "init" and "free". |
@Tertioptus I'm closing, since EO doesn't have constructors anymore |
How much does "onstruc" save you?
It seems like the code is based on an English-language base, why not keep it that way purely?
Developers should be adept with tools like vim, content assist, etc to complete tokens. This way you don't compromise the clarity of the language for the sake of convenience.
The text was updated successfully, but these errors were encountered: