Re: Objects and Relations

On Feb 9, 1:05 am, "David BL" <davi..._at_iinet.net.au> wrote:
> 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".

David BL: "I'm not aware of a formal definition of variable...". Perhaps it would behoove you to refresh you memory on the definitions of terms prior to criticizing the way others use them.

A variable is a reference to a value. Variable declarations determine the scope of the variable as well as constrain (by domain, behavior, implementation, representation, or some combination thereof) the values that the variable can reference. Assignment is the association (or binding) of a variable with a specific value and dereferencing is retrieving the value associated with a variable. Allocation involves locating and claiming resources to hold the physical representation of values to which variables are bound.

Based on the above and using your definition "object is the same as an instance of a class", your phrase "allocating an object from the heap" is utterly incoherent. Naturally, the more general version, "allocating a variable", is also incoherent. This shared incoherence in no way advances your argument that objects are not a kind of variable (if anything, it constitutes evidence to the contrary).

Had you prefaced your phrase with a clarification that data objects, unlike OO objects, refer to physical representations of a value; and then disambiguated the phrase "allocating an object from the heap", you would have arrived at the perfectly coherent "allocating a data object from the heap". Of course, this coherent version does not generalize into the incoherent "allocating a variable", so it wouldn't have advanced your argument either.

>
>
>
>
>
> > >>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?
>
> "Definition 1: Let Employee represent the entity type for a
> human ..."
>
> "Definition 2: Let Employee represent the object type ..."
>
> Should one justify the overloaded meaning in the name of brevity?
> Should it be assumed there is no confusion until proven otherwise?
>
> Amongst other things I'm concerned about how to interpret comments
> containing the word "Employee" in the code.
>
>
>
>
>
> > 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.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Received on Fri Feb 09 2007 - 17:45:27 CET