Op Fri, 29 Feb 2008, schreef Skybuck Flying:
There is another major drawback to your supposedly better method:
Object inheritance forces all fields to be accessable from the root:
SomeRoot.SomeField := ...;
While nesting has nice grouping:
SomeRoot.SomeHeader.SomeOtherHeader.SomeField := 5
-
From: "Daniël Mantione" <[EMAIL PROTECTED]>
To: "FPC-Pascal users discussions"
Sent: Saturday, February 16, 2008 5:24 PM
Subject: Re: [fpc-pascal] Empty record inside another record ?
Op Fri, 15 Feb 2008, schreef Skybuck Flying:
To me it seems like some kind of tr
Op Sun, 24 Feb 2008, schreef Skybuck Flying:
Finally there is another question remaining:
Are objects always packed ?
No, to get packed objects you have to declare them packed. A record and
object with the same field list have the same binary layout.
Daniël___
Sent: Saturday, February 16, 2008 5:24 PM
Subject: Re: [fpc-pascal] Empty record inside another record ?
Op Fri, 15 Feb 2008, schreef Skybuck Flying:
To me it seems like some kind of trick, to extend a record at runtime.
The empty record field, functions as a sort of offset/label/poin
cal users discussions"
Sent: Saturday, February 16, 2008 5:24 PM
Subject: Re: [fpc-pascal] Empty record inside another record ?
Op Fri, 15 Feb 2008, schreef Skybuck Flying:
To me it seems like some kind of trick, to extend a record at runtime.
The empty record field, functions as a sort
> The context in which the words are used determines their meaning.
And that's exactly the problem: good code is understandable with as
little as possible context. Any context depending behaviour/meaning
makes code less readable and less maintainable.
__
> In every language I know, words can have multiple meanings.
Natural languages yes. But they need a billion neurons that is trained for
20 years to interpret, not a simple automaton.
IOW, lots of computer languages don't.
> One possible reason could be because there is so much to describe that
In every language I know, words can have multiple meanings.
The context in which the words are used determines their meaning.
One possible reason could be because there is so much to describe that
coming up with unique words might be impossible or inpractical.
Bye,
Skybuck.
Skybuck Flying
Skybuck Flying schrieb:
> For records, I would use an extension field like:
>
> IP.Payload
>
> and
>
> UDP.Payload
>
> I would hardly call that obfuscation :)
Having the same name for different things is always obfuscation.
___
fpc-pascal maillist -
> For records, I would use an extension field like:
>
> IP.Payload
>
> and
>
> UDP.Payload
>
> I would hardly call that obfuscation :)
But the whole idea of inheritance is that child fields and methods are also
available in UDP.
Have a look at a basis OOP tutorial.
_
For records, I would use an extension field like:
IP.Payload
and
UDP.Payload
I would hardly call that obfuscation :)
Bye,
Skybuck.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 19 Feb 2008, at 10:16, Tiziano De Togni wrote:
Vincent Snijders ha scritto:
Tiziano De Togni schreef:
Florian Klaempfl ha scritto:
Skybuck Flying schrieb:
One drawback of objects already discovered:
am I correct?
This is not allowed in {$mode objfpc}, because of the reasons
Florian
Vincent Snijders ha scritto:
Tiziano De Togni schreef:
Florian Klaempfl ha scritto:
Skybuck Flying schrieb:
One drawback of objects already discovered:
am I correct?
This is not allowed in {$mode objfpc}, because of the reasons Florian
memtioned. It is allowed in {$mode delphi}.
Vincen
var
MyObject: TAncestor;
This is the problem.
it compiles correctly in Delphi (5 and 7)
Are you sure? It fails on my Delphi 7.
-Bee-
has Bee.ography at:
http://beeography.wordpress.com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.or
Tiziano De Togni schreef:
Florian Klaempfl ha scritto:
Skybuck Flying schrieb:
One drawback of objects already discovered:
Objects cannot have the same field identifiers.
Indeed, especially if you want to win an obfuscation contest.
ok, this is true for object type, but it should not be ex
Florian Klaempfl ha scritto:
Skybuck Flying schrieb:
One drawback of objects already discovered:
Objects cannot have the same field identifiers.
Indeed, especially if you want to win an obfuscation contest.
ok, this is true for object type, but it should not be extended to class
types. Look
Skybuck Flying schrieb:
> One drawback of objects already discovered:
>
> Objects cannot have the same field identifiers.
Indeed, especially if you want to win an obfuscation contest.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://li
Well ok,
I see one benefit of using objects so far.
No extension field needed per record/object, makes the code less complex ;)
Bye,
Skybuck.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fp
What's the benefit of using objects ?
One drawback of objects already discovered:
Objects cannot have the same field identifiers.
A problem that does not exist with records, and empty records.
// object example, pointers and typecasts still necessary.
program Project1;
{$APPTYPE CONSOLE}
us
Op Fri, 15 Feb 2008, schreef Skybuck Flying:
To me it seems like some kind of trick, to extend a record at runtime.
The empty record field, functions as a sort of offset/label/pointer if you
will to the new fields that will will be extended to the record by simply
allocating more memory the
20 matches
Mail list logo
