Re: Objects and Relations
Date: 8 Feb 2007 23:05:17 -0800
Message-ID: <1171004717.257590.155430_at_q2g2000cwa.googlegroups.com>
On Feb 9, 12:32 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Marshall wrote:
> > On Feb 7, 6:12 pm, "David BL" <davi..._at_iinet.net.au> wrote:
>
> >>On Feb 8, 6:26 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
> >>>>>Consider the following
>
> >>>>>void foo(Employee* p1, Employee* p2)
> >>>>>{
> >>>>> // Q1. What does this mean?
> >>>>> if (p1 == p2) ...
>
> >>>Conditional test whether p1 and p2 point to the same variable.
>
> >>Bob is confused about the difference between 'variable' and 'object'.
>
> > Objects are a specific kind of first-class variable. The term is not
> > popular in the OO world but it is nonetheless accurate.
>
> As Dr. Phil would say: David is levelling. To be perfectly accurate, p1
> and p2 point to memory locations. They could point to ROM or to memory
> mapped I/O devices. If they point to ROM, one could argue they point to
> something constant. That said, almost all memory locations address
> variables.
>
> However, 'object' has nothing whatsoever to do with the above. An
> instance of an object class is a variable. If the self-aggrandizing
> ignorant doesn't mean an instance of an object class when he uses
> 'object' above, he is actively trying to avoid communication.
object is the same as an instance of a class.
In common usage 'variable' is only used with reference to the identifiers in the source that at run time are associated with an instance of some type (whether a global variable, frame variable or member variable). I'm not aware of a formal definition of variable, but it's certainly unusual to say for example that allocating an object from the heap is also said to be "allocating a variable".
> >>Since the object type is (incorrectly) named
> >>"Employee" on casual reading it may appear to be true if and only if
> >>p1 and p2 designate the same Employee.
>
> > Just repeating the same claim over and over doesn't really advance
> > the coversation.
>
> He's just making up shit as he goes along. Just by acknowledging he said
> anything, we elevate his crap.
>
> >>In my designs I aim for correctness and brevity. Correctness is not
> >>negotiable. An incorrectly named class is not an option.
>
> > Of all the areas to worry about correctness, you're focusing on
> > naming? Naming is important, but I've never heard it elevated
> > to a correctness issue before.
>
> Speaking of the importance of naming, did you hear about the Hungarian
> space program?
>
> In any case, we have this from probably the most influential person on
> earth when it comes to naming:
>
> "If a quantity is incorrectly classified, we have a style problem, not a
> bug."
>
> http://msdn2.microsoft.com/en-us/library/aa260976(VS.60).aspx
The claim that incorrect naming doesn't represent a bug is true but amazingly short sighted. It is a pathetic argument. Good naming avoids bugs in the first place.
Would a mathematician do this?
> Do you imagine being able
>
> > to write some kind of theorem prover that will tell you
> > if a name is good or not? And how can you be claiming
> > brevity when you want to put a "-model" suffix on the name
> > of every class in the application domain?
>
> Face it--he's a self-aggrandizing ignorant. He declares something to be
> correct and everything else to be incorrect so that he has an
> unassailable position for self-promotion. ie. He becomes the de facto
> expert on what is correct.
> > You still haven't provided any evidence that actual programmers
> > actually get confused about something that they wouldn't
> > get confused about if they just used a suffix on the name.
>
> As Walt would say: "He's not even wrong.
What is Bob's motivation here? He's clearly not interested in the discussion itself. Received on Fri Feb 09 2007 - 08:05:17 CET