Naming of core concepts


Another part of naming that I’ve spent some time thinking about is what I should call the core concepts in the language. A typical example of this is using the word Object for the base of the structure. I’ve never liked this and I get the feeling that many languages have chosen this just because other languages have it, instead of for any good reason.

In a prototype based language it definitely doesn’t feel good. My current favorite name for the hierarchy base is right now Origin. Since everything is actually copied from this object, that word seems right.

Another naming issue that turns up quite quickly is what the things you store in an object is called. In JavaScript they are called properties. In Io they are called slots. It’s hard to articulate why I don’t like these names. Maybe this is a personal preference, but at the moment I’m considering calling them ‘cells’ in Ioke.

What about String? That does seem like an arbitrary choice too. A String is probably short for String of characters in most cases, and that’s really an implementation choice. What if you do like JavaScript engines where a String is actually a collection of character buffers stitched together? In that case String feels like a slightly suspect name. For Ioke I’m currently leaning towards just calling it Text. Text is immutable by default and you need a TextBuffer to be able to modify text on the fly.

Another thing that sometimes feel very strange in prototype based languages is the name you give the operation to create new instances. In Io it’s called clone. In JavaScript you use new. Here I’m really not sure what to do. At the moment I’m considering leaving it to ‘clone’ but provide two factory methods that will allow better flow while reading and also avoid the clone keyword. Say that you have something called Person. To create a new Person the code should look like this:

p = Person with(
  givenName = "Ola"
  surName = "Bini")

This code will first call clone, and then execute the code given to with inside of the context of the newly cloned object. This pattern should be quite common when creating instances. The other common person I see occurring is this:

tb = TextBuffer from("some text")

Maybe there are other useful cases, but with and from will work quite well for most purposes in the core libraries. What’s nice is that these methods are extremely easy to create and they don’t need any fancy runtime support. They are entirely composable from other primitives.

This is currently the kind of decisions I’m trying to make. If you have something that works nice instead of ‘clone’, do let me know.


16 Comments, Comment or Ping

  1. jean

    I think changing the name of the base concepts is not necessarily a good idea : it makes for a steep learning curve. Then it depends on your target population. If you want java/.NET/ruby devs to use ioke maybe sticking to object and new is a good idea

    September 30th, 2008

  2. What about using create? It follows from new or clone, but might provide a better flow. To me it straddles the line between new and clone, as it implies that an object is new, but not necessary an exact copy of another. It also seems to be implied in your post, but just not recognized:

    “… the name you give the operation to create new instances.”

    As developers we talk about creating objects or instances all the time – so why not call the command create? It’s precisely what is being done.

    September 30th, 2008

  3. Jean:
    I’m not really designing the language for anyone other than myself, actually. If someone else likes it, that would be fun, but I’m creating a language that I will be comfortable with – which means I’m fine with doing choices that will make for a steep learning curve.

    Mark:
    Yeah, I thought about that too. It might be better than clone in some regards, but it’s not exactly true either. I want a word that in some way includes information that gives a hint that the new object is not created from some class, but is actually copied from an existing object.

    September 30th, 2008

  4. I think that “Object” is actually a good name for the class hierarchy root. Why? Because when naming classes in a hierarchy, one should want the sentence “[subclass] is a [superclass]” sound naturally (like in “BufferedReader is a Reader”, “RuntimeError is an Exception”, etc.). It captures the actual relationship between the classes. For every class, the sentence “[something] is an Object” sounds OK and is true, but this is not the case for names like “Origin”.

    September 30th, 2008

  5. Love your “with” and “from” but the “clone” I dont get. But this might be because I am from a Java world. How about “construct” or “instantiate” (unfortunatelly both quite long) or using a symbol which has less sematics to it (like ~Text)

    Gruss
    Bernd

    September 30th, 2008

  6. Hey Ola!

    Great to hear some news about Ioke!

    I quite liked Origin as well – it’d be even better if Origin descended from Nil :)

    new, with, from, create, build, init and alloc are all good names for these sorts of methods – I’d rather be allowed to use any of these as a “constructor”, and I assume Ioke will let you pick and choose when necessary. But, as a default, how about with()? It sounds easier to fit in various english-like sentences to me.

    September 30th, 2008

  7. David:
    Your example makes perfect sense – in a class based OO language, which Ioke is not. Specifically saying that something is a subclass or superclass of something else is totally incorrect, since that’s not the relationship they have. And that’s why I’m less convinced about the word Object. And if you try the sentence you can see that is derived from Origin works quite well, for example. And it also describes the relationship better.

    Bernd:
    Clone comes from the Io language, and it actually quite closely describes what the operation does. Symbols I’m not using – I don’t want to restrict things by having syntax. Construct or instantiate is both quite fine but long as you say. They are also low level. Richard Gabriel gave me the proposal to use ‘mimic’, and I quite like that. Another word I came up with is ‘derive’. These are higher level and describes the intention.

    Carlos:
    Glad you like it.
    I’m probably going with either ‘mimic’ or ‘derive’. Like them both.

    September 30th, 2008

  8. Ade

    How about ‘twin’? Just a thought, mimic and derive are both excellent.

    Your idea to use ‘cell’ as the name for a property is interesting and makes me think that you could perhaps use biology as an inspiration for many of your syntax choices. If so then words like ‘twin’ and ‘mimic’ would be better than ‘derive’, as twinning and mimicry are both seen in nature (or course derivation is as well but it seems more abstract).

    ‘Origin’ also fits into this well.

    October 1st, 2008

  9. I like Origin!
    Object is clearly not appropriate for prototype-based languages. In Protalk I have chosen Thing due to lack of a better name.

    @Cell, I just started with a language where objects are composed of delegation-based fragments which are called “cells”. Alas, I did not go any further with the biology metaphor yet…

    October 2nd, 2008

  10. The Ponderer

    Why do you always wear that hat?

    October 2nd, 2008

  11. David Mathers

    I was just studying self a few days ago. In self the root object is called the lobby: “The lobby object is thus named because it is where objects enter the SELF world.”

    October 2nd, 2008

  12. Why not use Person() when there are no parameters and Person with(params…) when there are parameters.

    October 2nd, 2008

  13. Mimic sounds perfect. Give you the right idea, clone sounded a bit suspicious, almost as a copy (even when is not really). And I quite like Origin. The name that actually strike me as perfect is Text, String never sounded good to me. Cell is odd If you think about it as a biological Cell but makes more sense if I think it as a container Cell, a place where you put “stuff”. What about methods?

    October 3rd, 2008

  14. Ola –

    Did you ever come to a decision? Scanning the post and comments I don’t see one, but I could have missed it. I read this post so long ago and offered my suggestions, I had forgotten about it, but was reminded of it the other day when I finished reading Steve Yegge’s post on the Properties pattern. Steve’s post referenced prototyping and also talked about the clone operation and from reading what he wrote and thinking on it some I’ve come to think that clone might not be such a bad choice. I also went back and read the Gang of Four’s chapter on the Prototype pattern, which only further solidified my thoughts around using clone, instead of create, which is what I’d originally suggested.

    Yeah, it’s been over a month since you wrote this post, but I thought I’d revisit since my thoughts were dwelling on the topic.

    Thanks for doing this. While I don’t have the time or the desire to attempt to write my own language, I’m enjoying reading about your journey and all the interesting concepts and tradeoffs you encounter. It gives me a new appreciate for all the language designers out there and the hard decisions they have to make.

    November 4th, 2008

  15. Mark:

    Yes, I did come to a decision. I asked Richard Gabriel for advice on naming and he immediately gave me the word “mimic”. There are some problems with it, but in balance it works really well. You’re mimicking something else. The reason this is interesting is also because Ioke uses a structure where it’s not exactly cloning, but creating an object that points back to the object it was cloned from. Cloning implies that everything is copied, while mimicking doesn’t have this disadvantage.

    November 4th, 2008

  16. Ola,

    Interesting. I’ll have to download the source for Ioke and take a look. I’m curious to see how mimicking works because I’m not fully grasping the implications.

    How is this set up different from other languages? Does it change the side effects in the code?

    November 5th, 2008

Reply to “Naming of core concepts”