Re: CORE - Literal Instantiation breaks Object Model

Christopher Dicely already hit the most relevant OO and technical concerns, so 
I'll just address this:

On Friday, June 10, 2011 01:00:26 PM Ilias Lazaridis wrote:
> But: of course I can teach you something about the object model,
> especially because you have designed it. Because you are - as the
> language designer and implementer - far to deep in the internals, in
> order to view the model (and the language in general) strictly from a
> users view. You miss some basics - that's natural.

That's some pretty unbelievable arrogance. Really? Let's examine this:

> > String objects
> > for literals are already created in the compile time, which is far
> > before you redefine the initialize method.  
> 
> Basics: Interpreted language, OO
> 
> From my (OO user) point of view, there is no compile-time.

Of course there is, even from a "user"s point of view:

puts 'Hello, world!'
class Foo
  def bar
    if false
      a <> b
    end
  end
end

Execute that, and you find that despite the fact that this code will never run 
(and thus, will never be "interpreted"), the entire file will be rejected by 
Ruby at compile time. You'll never see that "Hello, world!" message because of 
a syntax error buried at compile-time, later.

As a user, compile-time is also relevant to why symbols work the way they do, 
and why they're so useful.

Pretending to be an uninformed user doesn't mean you're dealing with something 
more abstract or "pure", it just means you're less informed. For one thing, as 
Christopher pointed out, 'initialize' isn't the constructor, and having a 
separate 'initialize' method is something I've seen (and implemented) in other 
languages.

> Those are *not* String objects, as their related initialize method was
> not called (remember: my user OO-code supersedes naturally the core-
> level code)

While the notion of type is also orthogonal to OO-ness, I don't see that being 
relevant here. These are in every way String objects. If you define methods on 
String, those methods apply to String literals. This includes your initialize 
method:

oo_string = String.new("The OO String")
li_string = "The Literal String"
li_string.send :initialize, li_string
# Now the rest of the program works as you expected.

Their history is irrelevant. You're talking about what they are now, and they 
are, in fact, Strings, in every sense that is relevant right now.

> If those would be instances of a class like StringLiterals, it would
> be different.

No, it wouldn't. Then you'd be whining that when you overrode 'initialize' in 
StringLiterals, your initialize still wasn't called!

> > I don't feel
> > any need to call the (redefined) initialize method for string
> > literals, that already initialized at the compile time.  
> 
> This is not about "feelings" and "needs", but about strictness.

Matz appears to be saying that he'd rather not call the strings' initialize 
method twice. Do you really think "strictness", in any context, would be 
satisfied by calling initialize _twice_?

> If I use a valid language-construct to override the constructor, then
> the language *must* call the modified constructor in order to be
> compliant to the OO-model/language. If the language designer "feels"
> otherwise... then it has to control those feelings.
> 
> Or he must *clearly* state, that those are *not* objects of class
> String.

And as wrong as you've been, this is where you cannot possibly be more wrong.

Unless you have somehow become Matz' employer, he owes you nothing, and you 
are in no place to tell him (or anyone else) what they "must" do. Telling them 
this is not a recipe for cooperation.

And you do seem to care about cooperation.

> Neither here, nor on the issue-track I've asked you to "change the
> language (or its object model)",

Oh, but you have. You just did! In fact, you didn't "ask" him, you told him, 
you _demanded_ that he change the way the language behaves.

> The few issues that I've filed are for sure not "random popping
> ideas". Mostly, they are either user needs or usage barriers.

Giving us some context would go a long way towards establishing the truth of 
this.

> If a person with over two decades of experience in hard- system- and
> firmware-design shows interest to contribute on C-core-level, then you
> should encourage this instead of suggesting that he is trying to
> "hijack" the language.

Except you're not that person. You're some random guy on a discussion group. 
Even if you have the credentials you claim, and even if they are somehow 
relevant, we only have what you say here to go on. Your real credentials are 
your contributions to this discussion.

And your contributions have been things like telling the creator of a language 
that they don't understand their own language. You'd think that would be 
enough of a clue, without the entire community convinced you're not worth 
talking to.

You have it backwards. If you really do want to contribute, it isn't the 
responsibility of the core people to encourage you, it's your responsibility 
to demonstrate to them that it is worth their time to help you.

> The issue "Literal Instantiation breaks Object Model" is crystal-
> clear. It should not take anyone more than 15min. to accept it as a
> "known issue, trade-off for execution speed". That's really nothing
> special.

Are you surprised that you now have several responses that disagree with you? 
Why do you think that is?

Think about it.