On 2010-06-09, at 15:21 , chevalma@iro.umontreal.ca wrote:
You did not answer this important question: how will a *client* module know that mem is a namespace with read-only fields (thus enabling the compiler to perform direct jumps)?
There are many ways to achieve this. One is a naive analysis. Only one write to mem.foo + no evals + we trust our own code, means a single point of definition.
There is also a general principle that aims to keep the trusted code base as small as possible. Sure, the initial tachyon devs might follow the guidelines perfectly, but more devs will be added to the project in the future (and replace some other devs). I don't think we can guarantee that this will *never* become a problem...
Another is to have the compiler detect patterns such as defineProperty(mem, "foo", {writable: false}) (I'm not sure of the actual syntax). We could even have a shorthand method to make attributes read-only in our compiler. defReadOnly(obj, field, val) or makeReadOnly(obj, field).
Introducing special cases adds more complexity. In general, I tend to avoid that as much as possible.
A third way is annotations. Have some JsDoc-style comment @readonly, or something, just above things we want to be read-only.
If it sorts by name then all the mem_xxx functions will be together. What's the problem?
It's still annoying to have to browse a huge file.
I don't see how the implementations issues with a *documentation tool* constitute valid arguments that affect the coding standards we use. If JsDoc is too naive to produce correct documentation, we use another tool, write our own, tweak this one, or even better yet, submit a feature request to the JsDoc devs.
It is not an issue with mem_xxx. But with mem.xxx you will be calling methods in the mem object before the fields are made read-only. How will tachyon deal with such a case (a namespace being used in the middle of its initialization)?
mem.xxx = function() {} makeReadOnly(mem, "xxx");
// Use xxx after this point
And you argue that this is simpler than the mem_xxx naming scheme? If programmers have to type it, it clearly isn't. If the compiler takes care of it, it introduces complexity in the compiler that shouldn't be there. To me, it's pretty much a lose-lose situation. Just my opinion though...
That's true, but lets put things into perspective... We are talking about a single character in the "function name", either a "_" or a ".". This is not exactly a big change in style! On the other hand we can expect a factor of 2 speed difference between "_" and ".". That's significant.
- We can easily make sure this speed difference does not occur in Tachyon.
Granted, we can introduce mechanisms to address this problem, but at a cost in terms of "clean" design, as I argued above.
- We should not prematurely optimize. Performance is hardly an issue when
we don't even have a remotely working compiler.
Given the nature of the task performed tachyon, performance is very much an inherent part of the design constraints. I wouldn't brush it off so quickly and easily. As Marc said many times, we could always switch to using namespaces later if we really want to. It would be very easy to automate the conversion.
- We aren't just talking about this one issue. There are plenty of other
cases where I'm sure you'll advocate a more "old-school", procedural, C-like design. Using JavaScript this way takes us away from the main benefit of using JavsScript: simpler, more readable code.
Readability is subjective, I personally find the mem_xxx syntax simpler and more readable than the @namespace annotations etc, which seem rather verbose in your small examples. I'm not trying to start a debate on defining the readability of code, but just pointing out that this is a rather weak argument and, in my mind, less important than others.
The mem_xxx style is clearly more KISS than the mem.xxx style.
I disagree. JavaScript is an OOP language. Using an OOP language in the most procedural way possible because you're worried that our optimizations will be so weak they won't be able to inline such trivial cases, even when we can guarantee that our compilee *will* in fact optimize these cases (because we can force it to, *if needed*), clearly goes against the KISS principle.
There's a difference between OO code and your namespace proposal. The namespaces are not objects per say, they don't represent the same abstractions objects normally do. There are no brownie points for using this so-called object syntax in arbitrary situations. On the other hand, we will encounter situations where objects will and should be the natural way to write the code.
Moreover, there's also a difference between believing that tachyon will eventually be able to optimize such code and completely eliminate the performance hit, and placing ourselves voluntarily in a situation where we have to do it before tachyon can be really useful. There are other features of the language that we will avoid using for similar reasons, I don't see this one as being special in any way.
*Premature optimization is also not KISS*... And this is clearly your main argument here, avoiding OOP/dynamic features as much as possible because you're worried about performance and want to constrain our design when we aren't remotely near the point where we can even run any benchmarks.
Again, I fail to see the namespace = OOP argument. As far as I am concerned, there is nothing conceptually OO with either syntax, so they shouldn't be compared this way.
I say, let's write simple, organized code, using the sensible features of the language. There are some obvious compromises I'm willing to make (no eval, for example), but please, let us organize the code nicely and tidily, let us benefits from some of the most useful JavaScript features, and let us refactor for performance and/or add annotations to the Tachyon code only if/when performance issues surface.
I simple, organized code is the aim of both proposals. We just need to carefully examine the costs and benefits on each side. So far, I favour the mem_xxx syntax because it offers the best cost/benefits compromise (and in my opinion, by a large margin). That being said, if you have really compelling arguments in favour of namespaces, I'll gladly reconsider my position.
Bruno