Reputation
618
Next privilege 1,000 Rep.
See votes, expandable usercard
Badges
5 9
Impact
~43k people reached

  • 0 posts edited
  • 0 helpful flags
  • 15 votes cast
Oct
10
awarded  Popular Question
Oct
8
comment Designing around shallow constness with inheritance
FYI try this for a start: en.wikipedia.org/wiki/…
Oct
8
comment Designing around shallow constness with inheritance
Sorry but it is hard in the restricted space of a comment here to present a proper case. Read some academic papers on subtyping and variance. The bottom line is that the variances permitted for a function in a sound type system alternate, so that the first argument may be covariant (accept a subtype) but the second one must be contravariant (accept only a super type). Binary methods require both arguments (the object being the first argument) to be covariant. Hence OO cannot be soundly typed. Therefore it cannot be a general paradigm.
Oct
6
comment Designing around shallow constness with inheritance
BTW: it turns out in practice an abstract representation of images is useless although possible. It is actually better to have unrelated classes for JPG, PNG, etc and just accept your application has to have a lot of methods, some of which work on some kinds and not others. GIF and PNG for example allow a list of frames which can represent motion but JPG does not. All these kinds do admit a conversion to a bitmap but in much modern practice you're using a renderer that works with a specific set of compact representation directly.
Oct
6
comment Designing around shallow constness with inheritance
And you may say "but there are operations on matrices which do not preserve symmetry". Good. You got it. OO doesn't work. Stop trying to build a perpetual motion machine. It's been proven, mathematically, to be impossible. In this case it is well known that the variances on a function of higher arity alternate, OO requires the second argument to be covariant, but it isn't, so OO is known and proven beyond doubt to be incapable of representing relationships (or any N-ary concept with N greater than 1).
Oct
6
comment Designing around shallow constness with inheritance
The "OO" is-a relation is exactly the one that one has in natural language. For example a symmetric matrix ISA matrix. It is a subtype. Every symmetric matrix is an example of a matrix. The word "sub type" means precisely the same as "subset of the values of".
Oct
6
comment Designing around shallow constness with inheritance
When you design a concept, it should ALWAYS be abstract. Never never never put data in such classes. The whole idea is to use derivation to isolate the abstract representation (by methods) from multiple possible concrete representations (none of which is ever known by name except at the point of construction).
Oct
6
comment Designing around shallow constness with inheritance
Of course const is useful, but it also creates problems. In balance it isn't worth it. IMHO, but of course that is expressed in hindsight. ("It was a good idea at the time") The "do something else" is simple enough. Using abbrevatiations: class II_by_delegation : public virtual II { MI *delegate; ... }. That is, II and MI classes are abstract, provide an implementation of an II with wrapper methods and a pointer to a MI, obviously not wrapping the mutators. Hope that makes sense.
Oct
5
answered Designing around shallow constness with inheritance
Oct
5
comment Designing around shallow constness with inheritance
This "solution" cannot work, nor can any other, because "const" is not a structure preserving operation (functor in the category theory sense). In particular I have a MutableImage* and up cast to an ImmutableImage* then the holder of the latter will be surprised when the image changes.
Jan
31
awarded  Yearling
Sep
24
awarded  Autobiographer
Sep
11
awarded  Necromancer
Mar
1
awarded  Necromancer
Nov
26
awarded  Yearling
May
12
comment Correct For Loop Design
C's for loop does not universally handle all cases with a fixed comparison in the predicate. If you use < you cannot stop a loop which reaches the maximum value of the control variable type (for some types). If you use <= you cannot skip the body of the loop for zero cases. There is therefore no formulation for an arbitrary integral type which works correctly for 0 upto and including maximum value of the type. You need to understand my problem: I am generating code (not hand writing it) for unknown type with unknown bounds.
Apr
25
awarded  Critic
Jan
30
comment How to verify/prove orthogonality of a programming language?
+1 for the idea of splitting out the sugar
Jan
30
comment How to verify/prove orthogonality of a programming language?
@joan: I'm not a Haskell programmer so it's a bit hard to say, but the presence in Haskell of "extremely high level functionality" is indicative of strong orthogonality: you simply can't have a coherent implementation of Monads or Arrows unless the rest of the language has substantial "orthogonality"
Jan
30
comment How to verify/prove orthogonality of a programming language?
@joan: well, lisp doesn't have any features so it satisfies the requirement in vaccuuo :)