Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>   You always succeed in returning to your favorite subject: Bashing
>>> "unsafe" languages. And in your world there's only one such language: C++.
> 
>> You know something?  It's getting "really tiresome and old" that every time 
>> I list problems with 5 or 6 different languages, you think I'm bashing on 
>> C++.
> 
>   5 or 6 different languages? Really?

Yeah. LISP, Java, C#, C++, Python, and Ada. That's the first post I said 
anything that could conceivably imply C++ wasn't perfect. I pointed out how 
you could violate encapsulation in each of them.

>   You started by making a reference to "unsafe languages" within the subject
> of modular programming as a reply to one of my posts

Yes.

>(clearly as a reference to C++), 

Except I specificly used the phrase "unsafe languages" because I knew if I 
said "C++" you'd go off the handle.  I was particularly pointing out that 
unsafe languages let you violate modularity. Whether it's OO modularity or 
non-OO modularity is irrelevant to whether unsafe languages let you violate 
modularity.

 > and later you said that C++ is the *only* unsafe OO language you
> know of.

But it's not the only unsafe modular language I know. But you were talking 
about OO in addition to modularity, so that's why it came up.

> After that you have been done nothing else than arguing why
> modularity in C++ is broken and why Lisp, Java and C# are so great.

I haven't said the others were great. I simply said I preferred the 
imperfections in C# to the imperfections in C++.

>   Yeah, sure. You really have been pointing out problems in "5 or 6 different
> languages", and I'm just being paranoid that you are concentrating a little
> too much on C++.

Honestly, it really seems like that to me. I'm sorry you have so much of 
your ego bound up in a programming language.

>> It's 
>> getting "really tiresome and old" that every time I point out problems with 
>> unsafe languages in general, you think I'm bashing solely on C++.
> 
>   You explicitly wrote that C++ is the only unsafe OO language you know of.

Yes, after you asked me about it.  I also asked you to name another unsafe 
OO language, but you didn't. There are other OO languages that you can 
bypass the safety on, but most people using them don't without knowing what 
they're doing, specifically for performance.

> You have been writing specifically about C++, not about "unsafe languages
> in general".

No. I was writing about unsafe modular languages. It turned into C++ after a 
while, when people started specifically saying you can't bypass the 
modularity in C++ like you can in the other languages.

>   And it's getting really tiresome and old that you act all innocent after
> a tirade of C++ bashing, saying that "I just wanted a serious discussion
> and honestly wanted to know more", when it's rather clear that you didn't
> really.

Well, if you start out with that assumption, I guess anything I say can be 
twisted to read that way.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> There are few other unsafe OOP languages I know enough about to discuss. Ada 
>> and C++ are the only unsafe OOP languages I know
> 
>   Ok, here's a couple more:
> 
> - Objective-C. Regardless of the name, has nothing to do with C++.

Hmm. Yes, ok, I'd forgotten about that one, since I looked at it way back in 
the NeXT days but never used it. Very good, thanks. That's another example 
of an unsafe OO language where the lack of safety can lead to lack of 
modularity with all the same problems as C++.

> - C#. Regardless of the name, has nothing to do with C++.

C# is only unsafe if you specifically tell it "hey, I'm doing something 
unsafe."  That doesn't really count, any more than a safe language that can 
call out to C libraries is "unsafe".

>   I still see no connection to "unsafe" languages and "reflection". Those
> were your inventions.

Yes. It's part of an ongoing conversation, you see. "Access to private 
members violates encapsulation."   "Yes, and here's other ways to violate 
encapsulation."  See?

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
>   You are seriously claiming that when you wrote "like, in unsafe languages,
> where a stray pointer can change private variables without going thru the
> class methods? :-)" as a reply to my post you were not directly and
> exclusively referencing C++, especially with that smiley?

Yes. I am seriously claiming that. The smiley is there to say "Gee, I bet 
Warp will assume I'm for some reason attacking him. Maybe I'll try to be 
friendly and head that off."

If I was intentionally tweaking you, I'd use a winky face. :-)

>   What other half-dozen "unsafe languages, where a stray pointer can change
> private variables" were you talking about there?

C, for one. Any of the usually-safe languages that specifically bypass the 
safety features, like Ada using unchecked features or Eiffel with the 
precondition checking compiled out.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > - C#. Regardless of the name, has nothing to do with C++.

> C# is only unsafe if you specifically tell it "hey, I'm doing something 
> unsafe."  That doesn't really count

  Of course it doesn't.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   What other half-dozen "unsafe languages, where a stray pointer can change
> > private variables" were you talking about there?

> C, for one.

  Except that C doesn't have private variables.

-- 
                                                          - Warp

Post a reply to this message

Warp escreveu:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> Warp wrote:
>>>   It breaks modularity badly. The whole idea of data hiding is that the
>>> private part should be completely opaque to the outside. The second it
>>> isn't, outside code will start making assumptions, and you can't change
>>> the implementation of the class anymore.
> 
>> You CAN change the implementation of the class. It's not your problem if you
>> break code that made assumptions.
> 
>   I don't think that's a good programming principle.

Me neither.  But that's a bad programming principle by the dumbass 
accessing stuff it shouldn't.  It's not your fault as the module 
provider and is beyond your control.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> - C#. Regardless of the name, has nothing to do with C++.
> 
>> C# is only unsafe if you specifically tell it "hey, I'm doing something 
>> unsafe."  That doesn't really count
> 
>   Of course it doesn't.

Or, at least, it falls into the same category as using reflection. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>>   What other half-dozen "unsafe languages, where a stray pointer can change
>>> private variables" were you talking about there?
> 
>> C, for one.
> 
>   Except that C doesn't have private variables.

Sure it does. Everything in a FILE structure is a private variable. 
Everything on the stack is private variables. You're reading things too 
narrowly.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Warp wrote:
>   You are seriously claiming that when you wrote "like, in unsafe languages,
> where a stray pointer can change private variables without going thru the
> class methods? :-)" as a reply to my post you were not directly and
> exclusively referencing C++, especially with that smiley?

BTW, I think it's at least as realistic a claim as

 >  The connection between my usage of the word "kludge" and your usage
 > of the words "unsafe" and "reflection" is purely your invention.

Seriously, I'm willing to admit we seem to miscommunicate a lot. But telling 
me I'm always misinterpreting you, then telling me I'm lying when I tell you 
you're misinterpreting me is a bit unpleasant.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> He's saying that putting "private:" before the variables in a class 
> declaration is equivalent to naming private variables with an underscore. In 
> the first case, the compiler warns you if you use a private variable by 
> mistake. In the second case, it's obvious from inspection. If you have
>     x._y
> in your code, you're doing something wrong. :-)

  Btw (not flaming here), what would be the naming convention for nested
classes? Take, for example, this kind of situation, in C++ code:

class OuterClass
{
 public:
    // Public interface here.

 private:
    // Outside code should not access anything from this point forwards.
    // This includes the 'InnerClass' class below.

    class InnerClass
    {
     public:
        // Public interface for OuterClass to use.

     private:
        // Private members of InnerClass. OuterClass should not access.
    };
};

  While it becomes complex, it's possible to have even a *third* nested
class, inside 'InnerClass', with the equivalent access rules.

  (Defining 'InnerClass' outside of 'OuterClass' is not a viable solution
if I really want 'InnerClass' to be strictly inside the scope of
'OuterClass' and nowhere else, because my class design calls for this.)

-- 
                                                          - Warp

Post a reply to this message