What is the real reason for limiting inheritance to max 16 levels? I see no
problem having no limit at all.
/Emil
2012/6/18 Bruce bbr...@paddys-hill.net
On Sun, 2012-06-17 at 18:06 +0200, Emil Lenngren wrote:
Instead of overriding, why not simply create a module that does things
with
your
Le 18/06/2012 13:24, Emil Lenngren a écrit :
What is the real reason for limiting inheritance to max 16 levels? I see no
problem having no limit at all.
/Emil
16 is arbitrary, but a limit is necessary for one algorithm in class
inheritance management.
Anyway if you need more than 16
Even if most projects don't need more than depth 16, there might be some
very large projects (like Bruce's) that need it. Even well-designed
projects can have a large class tree.
And it is relatively easy to make that algorithm max depth-independent.
First see at what depth the current class is
On Mon, 2012-06-18 at 14:32 +0200, Emil Lenngren wrote:
Even if most projects don't need more than depth 16, there might be some
very large projects (like Bruce's) that need it. Even well-designed
projects can have a large class tree.
And it is relatively easy to make that algorithm max
Le 18/06/2012 14:32, Emil Lenngren a écrit :
Even if most projects don't need more than depth 16, there might be some
very large projects (like Bruce's) that need it. Even well-designed
projects can have a large class tree.
And it is relatively easy to make that algorithm max
Haha lol.
I looked up the class hierarchy for LLVM, which is a quite large project,
and the longest chain had 9 classes.
/Emil
2012/6/18 Bruce bbr...@paddys-hill.net
On Mon, 2012-06-18 at 14:32 +0200, Emil Lenngren wrote:
Even if most projects don't need more than depth 16, there might be
You don't need to call alloca(). Simply use something like this:
CLASS *her[get_the_size()];
It is valid in C99.
2012/6/18 Benoît Minisini gam...@users.sourceforge.net
Le 18/06/2012 14:32, Emil Lenngren a écrit :
Even if most projects don't need more than depth 16, there might be
some
I would like to override the Variant[] class to extend it with a small
set of special interest methods.
The gambas IDE complains when I try to call my class Variant[].
I cannot find anything in the help that seems to preclude this, apart
from the class naming rules.
Is this possible?
(More
On Sun, 17 Jun 2012, Bruce wrote:
I would like to override the Variant[] class to extend it with a small
set of special interest methods.
The gambas IDE complains when I try to call my class Variant[].
I cannot find anything in the help that seems to preclude this, apart
from the class
On Sun, 2012-06-17 at 13:45 +0200, tobi wrote:
I have done overriding Variant[] successfully (extended it by a specific
Sort() method) but it
caused an interpreter complaint (I do not use the IDE) until (excluding) rev
#4715 so it would be
interesting what message you get and what revision
Le 17/06/2012 08:22, Bruce a écrit :
I would like to override the Variant[] class to extend it with a small
set of special interest methods.
The gambas IDE complains when I try to call my class Variant[].
I cannot find anything in the help that seems to preclude this, apart
from the class
On Sun, 17 Jun 2012, Benoît Minisini wrote:
Le 17/06/2012 08:22, Bruce a écrit :
I would like to override the Variant[] class to extend it with a small
set of special interest methods.
The gambas IDE complains when I try to call my class Variant[].
I cannot find anything in the help
Le 17/06/2012 15:40, tobi a écrit :
On Sun, 17 Jun 2012, Benoît Minisini wrote:
Le 17/06/2012 08:22, Bruce a écrit :
I would like to override the Variant[] class to extend it with a small
set of special interest methods.
The gambas IDE complains when I try to call my class Variant[].
I
Le 17/06/2012 15:49, tobi a écrit :
Didn't know what?
That '[', ']' are not allowed in project file names. So the only reason for
which I was able to
override Variant[] was because I didn't use the IDE?
At the moment, I think that it works. But I may change in the future.
This is the
Instead of overriding, why not simply create a module that does things with
your array instead?
Instead of
Public Function Decode(ivar as String[], pattern as Integer[]) as
Variant[]
in some new array-class,
you can simply have
Public Function Decode(array As Variant[], ivar as String[],
On Sun, 2012-06-17 at 18:06 +0200, Emil Lenngren wrote:
Instead of overriding, why not simply create a module that does things with
your array instead?
Instead of
Public Function Decode(ivar as String[], pattern as Integer[]) as
Variant[]
in some new array-class,
you can simply have
16 matches
Mail list logo
