Re: Class objects work like built-in types, but is it worth it?
On 2008-10-28 23:21, tonytech08 wrote:
On Oct 28, 4:14 pm, Erik Wikstr??m <Erik-wikst...@telia.com> wrote:
On 2008-10-28 21:29, tonytech08 wrote:
On Oct 28, 1:55 pm, Erik Wikstr??m <Erik-wikst...@telia.com> wrote:
On 2008-10-28 16:00, tonytech08 wrote:
On Oct 26, 2:49 pm, Erik Wikstr??m <Erik-wikst...@telia.com> wrote:
On 2008-10-26 05:07, tonytech08 wrote:
On Oct 24, 4:25 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
tonytech08 wrote:
On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
tonytech08 wrote:
(like they are in
some languages). While in some cases this would be a useful thing (which
is the reason why those some languages do it in the first place), this
would seriously hinder the efficiency of built-in types.
It wouldn't change built-in efficiency in the least or in any way.
Exactly how would you create a generic data container which supports
both built-in types in the most efficient way possible *and*
user-defined classes if, as you suggest, the latter do not behave like
built-in types?
Why is that important?
Consistency is very important when writing software, we do not need the
additional complexity of having different containers for different
types.
Pushing complexity to another area is just pushing it around rather
than finding an elegant solution. And yes, sometimes the elegant
solution has some amount of compromise to avoid that complexity. If
one is real anal about it, well, C++ the language may be what you end
up with? "Refactoring" the language may be in order (on alternative).
To me it seems like we pushed the complexity all the way out of existence.
Ha! C++ is complexity incarnate! Pushing stuff into the compiler is
not reducing complexity, it's just moving it elsewhere.
First of all I do not agree that the complexity for the compiler is
increased by any significan amount (after all, every abstraction that
takes you away from assembly-language is added complexity) but
constructors and such are relatively simple.
It's not just compiler-called constructors. The compiler-called
constructors give rise to implementing exceptions, mentioned earlier
in this thread (probably more than once).
Also mentioned earlier is the fact that constructors does not
necessitate exceptions. Examples of why one would want exceptions
regardless of the presence of constructors (or even objects) have been
given, as has examples of how one could have constructors without
exceptions.
If you need to different containers (one for built-in types and
one for others) it means you need two sets of code, which meant you
double the amount of bugs, double the maintenance const, double the
things to keep track of, etc.
So, how many linked lists of integer values have you used in code? It
appears that not supporting built-in types for some containers would
encourage better programming practice (going by just that one
example).
Linked lists? None in any non-trivial program, but I've used vectors
(lots of them), heaps, stacks, and queues with integers.
The one who said "it means you need two sets of code" above someone
with the paradigm that containers are value-based things, probably
because of some kind of derivation of what a container is based upon
built-in arrays, which leads to "hence, class objects need to behave
like built-in types to be used by value-based containers", was why I
posed the "how many linked lists of integers..." question and
"theory" that value-based containers aren't even desireable mostly.
I will not speculate about his reasoning but I can say this: The fact
that the container can also handle class-types have been useful in some
situations (for example I can switch to debugging by just changing a
#define/typedef).
I was suggesting that handling built-ins as value-based containers was
probably the wrong design paradigm for containers and that shoehorns
class objects into a requirement to behave like built-ins (which is
not necessarily lucrative).
And I suggested that it was not true.
In fact, if classes where to behave like built-in types we would not
have a need for constructors (since built-in types are not initialised
on creation) and thus, by your reasoning, no need for exceptions either.
I think that both arrays and lists (as used in functional
languages) are containers.
Built in arrays are different beasts. It would probably not be
prudent to make the "raw materials of composition" (built-ins), class
objects. One can wrap those for more specific purposes.
Not sure what you mean here.
2 separate thoughts, should have been separated with paragraphs. 1.)
Built-in arrays and "containers" are not synonymous at a practical
level (sure if you wanted to be way abstract and talk about algoritms,
it might make sense, but in this thread, no.).
At a practical level I think arrays are containers, you can store
objects in them. Or put another way, arrays contains (hint, hint) objects.
2.)Getting back to the thread topic, making built-ins class objects
is probably a bad idea.
Actually I think it's a good idea, then there will be no distinction
between built-in and user-defined types.
Or did you mean making user-defined types behave like built-ins? You
have been repeatedly claimed it to be a bad idea but I've yet to see any
convincing arguments. You have mentioned constructors and exceptions as
being problematic but as I pointed out earlier in this post that simply
does not hold.
But the topic ponders is making class objects behave like built-ins a
bad idea at some level also (?).
No, reducing the distinction between user-defined types and built-in
types simplifies the logical model, makes it easier to write reusable
code, easier to maintain and change code, and probably makes it easier
to implement also (since compilers and tools does not have to make any
distinction).
My original
question is still open. Maybe there are 2 (or more) types of classes:
those that behave like built-ins and those that are something else.
That "something else" being lightweight and not nearly as complex as
requiring compiler-called constructors and then exceptions to solve
the "problem" with constructors.
In my experience its the classes that do not behave as built-in types
that are the more complex ones (singletons, non-value semantics, etc.).
Maybe even most classes (?).
Yes, most classes behaves like value types. Especially those that I use
a log. Those that do not have value-semantics are more rarely used and
not so numerous. At least that's my experience.
If so, whether the subset of classes that need built-in-like behavior
justifies all the related machinery is the question.
Since the subset is the majority I think it is safe to assume it does.
Besides, you still have not shown that there is any extra "machinery"
needed (by extra I mean something that can not justify it's own
existence in isolation).
Maybe it does, maybe it doesn't. Value-based containers require some
level of built-in type behavior from class objects and that seems
"too big of a pill to swallow" where simplicity/minimalness is valued
or the goal.
Most programmers find it very intuitive and you usually don't have to do
anything to get the behaviour. On the other hand any other behaviour is
less intuitive and requires more manual labour. So it seems to me like
value-semantics is the simpler approach. Besides, you have to look at
the full picture. Having two classes of types is not minimalistic.
I'm probably suggesting that classes should be designed NOT as
built-in types unless "it hurts not to" and that value- based
container "incompatibility" is "bad container design/ architecture"
rather than a point to justify built-in behavior from class objects.
In general it does hurt not do have value-semantics for types. Even in
Java and C# where most types have reference-semantics people program as
if they had value-semantics, and the GC makes this transparent to the user.
If you want something else you will end up with a very different
programming paradigm. Perhaps you should try functional programming,
usually those languages does not allow you to change the value of an
object once it has been assigned.
I think I've noted before or above that if you start with the thought
that "a built-in array is a container", a perverted definition of
"container" will result. A built-in array is a type rather than a
container (by "my" definition of container anyway).
Actually if we say that an array is a container we say that it fulfils
the requirements of a container, not the the requirements of a container
is to be like an array. Or in OO terms: an array implements the
interface container, but there might be many other implementations of
the same interface.
That's not topical though, and is paradigmical and a very
high-level/abstract "definition" (and even moreso, a definition of
"container interface" rather than "container").
It's a
definition of a container in terms of an interface, i.e. the interface
specifies what a container is and everything that implements the
interface is a container.
Nah, that's just a behavioral specification. A container interface is
not a container just like a remote control is not a television. The
remote just allows interaction with it.
In my work we design nodes in networks (some might call them servers but
I don't think that's a good description) which communicate with each
other and other nodes in networks. The requirements on these nodes are
specified by a standardisation organisation and the way they are
specified are in they way they interact with other nodes in the
networks. In other words the specification of a node is a description of
its interfaces. What I want to say with this is that a specification of
behaviour can be a sufficient definition of a thing. So an interface
description of a container can be a definition of a container.
Containers were brought into the discussion when someone said that
built-in-type-behavior of class objects is required so that
containers can be implemented, which of course is wrong in the
general sense.
Of course, but he only said that it is necessary to implement practical
and useful containers.
Which also is not true.
Says you, but who should I believe? A regular who's skills are
programming in general and C++ in particular I've witnessed, or you who
has so far only questioned what is more or less the collective opinion
among C++ programmers?
--
Erik Wikstr??m