Am 13.09.2010 14:51, schrieb Willibald Krenn:
Well, it's the Delphi way of creating a new type rather than an
alias.
Since they are still assignment compatible, I don't consider it as
a really new type.
Are you sure they are assignment compatible?
I don't have a delphi here, but I'am
- Sven Barth pascaldra...@googlemail.com schreef:
Am 13.09.2010 14:46, schrieb Dimitri Smits:
as said before, inspiration can be had from how they do it, but that
doesn't mean fpc should do it that way. Especially in a crossplatform
context, and more so cross-architecture, it is not a
Am 14.09.2010 01:26, schrieb Willibald Krenn:
[lots of useful information snipped]
- The ability to import/export functions, procedures AND variables
from binaries (although export from shared library only should be
sufficient). This works on Windows, but on Linux I had problems.
Packages
[lots of useful information snipped]
- The ability to import/export functions, procedures AND variables from
binaries (although export from shared library only should be
sufficient). This works on Windows, but on Linux I had problems.
Packages also export/import RTTI, ClassVars, types, all
Sven Barth schrieb:
[snip]
In theory(!) it should be rather simple to implement shared cross
platform packages (those that are loaded on app startup by the OS and
not dynamically during the run).
Thanks for the hints! They are very welcome.
Cheers,
Willi
Am 14.09.2010 01:26, schrieb Willibald Krenn:
[lots of useful information snipped]
- The ability to import/export functions, procedures AND variables
from binaries (although export from shared library only should be
sufficient). This works on Windows, but on Linux I had problems.
Packages
On 13/09/2010 14:16, Florian Klaempfl wrote:
Am 13.09.2010 14:51, schrieb Willibald Krenn:
Well, it's the Delphi way of creating a new type rather than an
alias.
Since they are still assignment compatible, I don't consider it as
a really new type.
Are you sure they are assignment
I don't know whether it is still the case but there was a time the 'is'
operator relied on RTTI. So as soon as you have two different RTTI
entries for, e.g., TMyListinteger (which could happen if you compile
with packages) the operator needs some 'repair'.
This is why FPC has specialize
This is why FPC has specialize (to emphasis this): only class instances
having the same specialized generic type are considered being equal:
type
TList1 = specialize TListLongint;
TList2 = specialize TListLongint;
var
l1a,l1b : TList1;
l2 : TList2;
Only l1a and l1b are
Am 13.09.2010 11:44, schrieb Willibald Krenn:
This is why FPC has specialize (to emphasis this): only class
instances having the same specialized generic type are considered
being equal: type TList1 = specialize TListLongint; TList2 =
specialize TListLongint;
var l1a,l1b : TList1; l2 :
OTOH 'specialize' is an additional
(unfamiliar) keyword and has semantics totally unknown to the world.
So why not take what's already in the language?
As I said, to emphasis that a new type is created, generic
specialization is something really new to the language. The meaning of
type
Am 13.09.2010 12:31, schrieb Willibald Krenn:
OTOH 'specialize' is an additional (unfamiliar) keyword and has
semantics totally unknown to the world. So why not take what's
already in the language?
As I said, to emphasis that a new type is created, generic
specialization is something
Am 13.09.2010 11:44, schrieb Willibald Krenn:
But enough about generics, back to packages: I'll start doing an implementation
for the non-generic part first. Let's see how this goes. Since I need to read
into fpc source (and do this in my spare time), don't expect any spectacular
results
- Sven Barth pascaldra...@googlemail.com schreef:
Am 13.09.2010 11:44, schrieb Willibald Krenn:
But enough about generics, back to packages: I'll start doing an
implementation for the non-generic part first. Let's see how this
goes. Since I need to read into fpc source (and do this in
Am 13.09.2010 14:02, schrieb Sven Barth:
Am 13.09.2010 11:44, schrieb Willibald Krenn:
But enough about generics, back to packages: I'll start doing an
implementation for the non-generic part first. Let's see how this
goes. Since I need to read into fpc source (and do this in my spare
time),
Well, it's the Delphi way of creating a new type rather than an
alias.
Since they are still assignment compatible, I don't consider it as a
really new type.
Are you sure they are assignment compatible? I thought the whole point of the
type A = type B was to make a new type, not an
Am 13.09.2010 14:46, schrieb Dimitri Smits:
- Sven Barthpascaldra...@googlemail.com schreef:
Am 13.09.2010 11:44, schrieb Willibald Krenn:
But enough about generics, back to packages: I'll start doing an
implementation for the non-generic part first. Let's see how this
goes. Since I
On Sun, 12 Sep 2010, Willibald Krenn wrote:
Hi!
Today I was thinking about fpc packages (whenever I am using this word, I
mean Delphi-style-DLL-packages) and what difficulties might arise when
implementing them. In my opinion, doing packages for D6-like Pascal should
not be conceptually
In our previous episode, Willibald Krenn said:
the correctness of the use of a value with a generic type without the
need for specialization. Here is a catch: Pascal has quite a lot of
types that are not classes. And this makes things a bit uncomfortable.
I would say that it is (almost)
Michael Van Canneyt schrieb:
Packages have nothing to do with the language feature. The difficult thing
is run-time resolving of all symbols. What the nature is of these
symbols is really not relevant.
Pardon my ignorance, but why is runtime resolving so difficult? There is
a fine Delphi
Marco van de Voort schrieb:
No it won't. Not all of the implementation of a package needs to be in the
.BPL equivalent. Neither is the case in Delphi.
Seek for $weakpackage and read the packages wiki again
In words of Borland/Embac - Unit files containing the {$WEAKPACKAGEUNIT
ON}
In our previous episode, Willibald Krenn said:
No it won't. Not all of the implementation of a package needs to be in the
.BPL equivalent. Neither is the case in Delphi.
Seek for $weakpackage and read the packages wiki again
In words of Borland/Embac - Unit files containing the
Marco van de Voort schrieb:
No, since any specialization creates the actual types, and they all will
have their respective static fields anyway? (since the static field can be
of the variable type)
There are some languages/runtimes that have some damage control here (most
notably C# which uses
In our previous episode, Willibald Krenn said:
There are some languages/runtimes that have some damage control here (most
notably C# which uses constraints to limit the definition to classes
implementing a certain interface, and it is said to typically share
specializations for such
Marco van de Voort schrieb:
Played around with Delphi today, and it seems that class vars are
somewhat broken on generic types. They work as expected (share common
class value amongst all sameclasssametype instances) only in a unit
scope, it seems. Which is a pitty.
To be honest, that is
25 matches
Mail list logo
