[E-Lang] pending revision of E in a Walnut

[Marc Stiegler]

> The default new() method seems suspicious to me.  I haven't done enough E
> programming to see whether the implications are parallel to those in Java,
> but there's are several reasons why Agorics' coding standards forbid
> reliance on the default new() method provided by Java.  First, it's always
> public, which may not have a bearing in E, but I'm not sure.  (If you
> don't want to let some clients call new(), what do you have to do?)  In
> Java, the new() method always nails down the actual type of the object
> being created.  It can't be virtualized like other methods, because of the
> way it's implemented primitively.  Finally, there are some kinds of
> initialization that can't be done in the constructor, and so allowing
> clients to call new() can mean that they get uninitialized objects.
> Having to explicitly code all the other methods to ensure the
> initialization code is called is vastly inferior to ensuring that the
> public factory methods return only initialized objects.

In E, the class declaration

class objMaker() :type {...}

is just syntactic shorthand for

def objMaker {
    to new() :type {...}
}

So you can virtualize it just the way you virtualize anything else, and
properties of initialization work the same way they work for anything else.

> Second, I wonder whether there aren't security implications of treating
> the arguments to the constructor as instance variables.  Does this make
> it
> easy to forget to make copies of them?  Will this lead to subtle
> problems
> with wall-banging or other kinds of leakage, since the object the client
> supplied is known to be the one held by the object?

I haven't seen a security issue with it. When passed without additional
information, they come through as "def" definitions, i.e., final. As for
wallbanging, the two following forms have the same wallbanging properties,
so it doesn't add any new problems to the wallbanging issue (which E doesn't
try to solve, incidentally):

def func(arg) {
    #use arg
}

def func(arg) {
    def argCopy := arg
    #use argCopy
}


> Under "Inheritance", you say "Some experts consider inheritance to be a
> dangerous feature of programming languages [...]".  Does this statement
> apply only to implementation inheritance?  Because I consider type
> inheritance to be the root of polymorphism, which seems to me to be the
> source of most of the power and benefits of OOP.
>
> Later in that paragraph you say "none of the full-blown examples in this
> book actually use inheritance."  I guess that reminds me that I haven't
> seen much use of polymorphism.  (Other than in the coordinate spaces
> code
> MarkM sent as part of a different discussion, but I haven't figured out
> how that works yet.)  I realize that E doesn't have strong typing, but
> if
> it also deemphasizes polymorphic types, I'm likely to be disappointed.
> Why is this section here?  Do you have an aversion to type hierarchies
> or to
> polymorphism?  If not, I'd suggest being clear what aspect of
> inheritance
> you're advising people to avoid.  If that is the point, I'd like to hear
> what I've been doing wrong all these years. :-)

It's the type hierarchies that cause religious wars here in the e-lang list.
In E in a Walnut, if you just search for each usage of "delegate {", each of
those is, I believe, a usage of polymorphism. There aren't a lot of such
usages in Walnut at the moment, largely because most of the examples are
missing at the moment :-) I will think about what else I need to say more
explicitly about polymorphism in the book.

> Under Arrays and primitive types, it looks like the example is part way
> through a migration between bytes and ints.  You import the type "byte"
> from java, then define "byteArray" to be an array of ints ("int[300]").
> I think the rest of the discussion assumes bytes.

Already fixed in my current draft. Thank you.

> In the explanation of the Eventually operator, you have a race car in the
> example, and use at least three confusing senses of "move".  The main
> method that appears is moveTo().  In the second paragraph, you say the
> program "immediately moves on the the next sequential statement."  In
> the
> fourth paragraph, you tell the reader she does not "need to know where
> the
> car is."  You've just been sending moveTo() messages to the car and
> talking about the car's position in 2-space, and now you
> mean to emphasize an agnosticism about where the code is executing.
> Please use a method other than "moveTo()" to explain this point.

Fixed in my current draft, I believe because you told me about this several
months ago. Thank you again :-)

--marcs