There was some discussion of TStringList and people asking for a different
base of work along these lines... I might have something.
Actually, whether or not he remembers - Michael Van Canneyt (Forgive my
spelling if I'm wrong) like 5 years ago explained some very important
"class" inner workings
Op Mon, 22 Jan 2007, schreef Felipe Monteiro de Carvalho:
> Maybe the compiler could hide the
> procedurization/re-object-orientation, thus making interfacing easier.
Already looked at many times, but it is not realistic.
Can you point me to previous discussion of this? Or perhaps a short
expla
On 1/22/07, Daniël Mantione <[EMAIL PROTECTED]> wrote:
Op Mon, 22 Jan 2007, schreef Felipe Monteiro de Carvalho:
> Maybe the compiler could hide the
> procedurization/re-object-orientation, thus making interfacing easier.
Already looked at many times, but it is not realistic.
Can you point me
Hi All,
Recently at my work place a non technical person asked me if I could
teach him some programming language, and after several minutes of
discussion regarding what is the best programming language to begin
with, I was able to convince him that Pascal is the best thing to
start with.
Now I h
On Tue, 23 Jan 2007, Luiz Americo Pereira Camara wrote:
> Daniël Mantione wrote:
> > Op Tue, 23 Jan 2007, schreef Luiz Americo Pereira Camara:
> >
> >
> > > Ale? Katona wrote:
> > >
> > > > I agree. I'm starting to feel sick of all the compat crap you guys put
> > > > up with playing the
Daniël Mantione wrote:
Op Tue, 23 Jan 2007, schreef Luiz Americo Pereira Camara:
Ale? Katona wrote:
I agree. I'm starting to feel sick of all the compat crap you guys put
up with playing the bitch of delphi. The problem is that now delphi is
the bitch of .net so I think wisest would be
Yes, this is the original purpose of interfaces in Delphi 3 and later:
reuse object code from different languages/executables through COM/DCOM or
CORBA. Both define standards for RPC (Remote procedure calling) and
passing arguments (type and size). An interface only exports member
functions
Op Tue, 23 Jan 2007, schreef Luiz Americo Pereira Camara:
> Ale? Katona wrote:
> > I agree. I'm starting to feel sick of all the compat crap you guys put
> > up with playing the bitch of delphi. The problem is that now delphi is
> > the bitch of .net so I think wisest would be to implement 100%
Aleš Katona wrote:
I agree. I'm starting to feel sick of all the compat crap you guys put
up with playing the bitch of delphi. The problem is that now delphi is
the bitch of .net so I think wisest would be to implement 100% compat up
to delphi 7 and be done with it. Then just document the fact an
Op Tue, 23 Jan 2007, schreef Bram Kuijvenhoven:
> Well, if for Chrome and/or Delphi support we need the &, then it will have to
> be implemented anyway.
Only if we are able to compile code we currently cannot compile. For
Chrome it would be a long term project before you can compile anything,
On Tue, 23 Jan 2007 08:36:13 -0200
"Felipe Monteiro de Carvalho" <[EMAIL PROTECTED]> wrote:
> On 1/23/07, Bogusław Brandys <[EMAIL PROTECTED]> wrote:
> > If libraries are using pure C then you are lucky.If C++ ,then the only
> > reasonable way for me is a thin wrapper DLL(s) :-(
>
> But imagine i
Marco van de Voort wrote:
Michael Van Canneyt wrote:
But, the 'importing identifiers' from another language is a false argument;
With a simple rule (prepend with _) you have this too. It can even be
automated. You don't need to butcher the language for it;
The _ trick is widely used indeed, bu
To clarify a bit...
Peter Popov wrote:
A
C++ class CANNOT have a virtual destructor (the VMT is killed when you
call delete, before the class' destructor is called).
Nope. Virtual destructors exist in C++, moreover good practice is to make
destructor virtual if any other method is virtual
>
> Thanks for the clarifying statement, Peter
>
> I's obvious that linking Object Pascal and C++ in that way is not possible.
>
> OTOH, is interfaces not invented for object based inter-language
> communication ?
Yes. But between willing partners, not for OOP language A to be able to
access a
Thanks for the clarifying statement, Peter
I's obvious that linking Object Pascal and C++ in that way is not possible.
OTOH, is interfaces not invented for object based inter-language
communication ?
So an interface based DLL layer, converting the C++ API of the OS to
interfaces FP could us
[EMAIL PROTECTED] schrieb:
>
> PS: I see now that the last source code for graph.pp file is revision 5862
> and my patch applies to 2.0.4, how do we solve?
> If it is accepted the simplest way should be to remove r5862 and
> reincorporate it by hand, I may make myself such.
A patch against t
On Tue, 23 Jan 2007, Thorsten Engler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> > So instead you'd put a & ?
> >
> > Hardly more readable, I'd say. On the contrary. _ is used
> > already, & is not.
>
> And that's exactly the reason for using & and not _. It's not part
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> So instead you'd put a & ?
>
> Hardly more readable, I'd say. On the contrary. _ is used
> already, & is not.
And that's exactly the reason for using & and not _. It's not part of a
valid identifier.
If you look at:
&class
You see directly i
On 1/23/07, Bogusław Brandys <[EMAIL PROTECTED]> wrote:
If libraries are using pure C then you are lucky.If C++ ,then the only
reasonable way for me is a thin wrapper DLL(s) :-(
But imagine if we require a dll to create apps for a operating system.
omg, that would look like vb!!! =)
It´s a no-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > The _ trick is widely used indeed, but imho those underscores make
> > code slightly less readable and also less aesthetic.
>
> Less readable than & ? What is the exact aesthetic ranking of
> [EMAIL PROTECTED]&*()_+ then? :-)
& is an proper esc
On Tue, 23 Jan 2007, Marco van de Voort wrote:
> > Michael Van Canneyt wrote:
> > > But, the 'importing identifiers' from another language is a false
> > > argument;
> > > With a simple rule (prepend with _) you have this too. It can even be
> > > automated. You don't need to butcher the langua
On Tue, 23 Jan 2007, Bram Kuijvenhoven wrote:
> Michael Van Canneyt wrote:
> > But, the 'importing identifiers' from another language is a false argument;
> > With a simple rule (prepend with _) you have this too. It can even be
> > automated. You don't need to butcher the language for it;
>
>
> Michael Van Canneyt wrote:
> > But, the 'importing identifiers' from another language is a false argument;
> > With a simple rule (prepend with _) you have this too. It can even be
> > automated. You don't need to butcher the language for it;
>
> The _ trick is widely used indeed, but imho thos
Michael Van Canneyt wrote:
But, the 'importing identifiers' from another language is a false argument;
With a simple rule (prepend with _) you have this too. It can even be
automated. You don't need to butcher the language for it;
The _ trick is widely used indeed, but imho those underscores m
On Ut, 2007-01-23 at 10:46 +0100, Michael Van Canneyt wrote:
> Well, ask them to support FPC, and code in FPC syntax.
>
> Why would we always have to follow them ? We were first on Linux,
> on all other platforms, we were the first with native 64 bit support,
> we were the first to introduce a
> > With Sun Java and MS J++ or .NET J# I try to use single Java code files and
I believe the financial leverage makes good Java IDE (IntelliJ IDEA or Eclipse)
hard to pursue (in this meaning).
If I get it right, FPC or Lazarus don't have resources to do it.
My point was: instead of trying to p
On Tue, 23 Jan 2007, George Birbilis wrote:
> >It may be implemented as some IDE plugin: auto substitution of some
> keywords and names (using comments to store display-names while naming all
> keywords
> >as they are and names as "nameXX").
>
> With Sun Java and MS J++ or .NET J# I try to
>It may be implemented as some IDE plugin: auto substitution of some
keywords and names (using comments to store display-names while naming all
keywords
>as they are and names as "nameXX").
With Sun Java and MS J++ or .NET J# I try to use single Java code files and
different projects pointing
On Tue, 23 Jan 2007, Thorsten Engler wrote:
>
> I also want to point out that I'm in no way proposing of adding this to any
> of the existing modes. I've added it to a new mode Chrome. As for "why do
> you want to get rid of...", for the same reason you do anything that you do
> in $mode delphi
If someone thinks, that there is something in these changes, there is no need
to change anything in the compiler.
It may be implemented as some IDE plugin: auto substitution of some keywords
and names (using comments to store display-names while naming all keywords as
they are and names as "nam
> c) new $mode: m_chrome
>
> Currently baseed on objfpc with the addition of all 3 new mode switches. In
> addition to a) and b) m_chrome allows the use of "method" as an alternative
> to both procedure and function (if the method is a procedure or function can
> simply be determined by the pres
> I'm very against this (especially in mode objfpc), and I don't get the
> point at all.
> In my opinion we have to keep the language as clean as possible.
Agree. Also note that this is only part of Delphi, whose compability is
still on hold. E.g. D7 reports "illegal character in input &($26)".
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> What could be a rood reason to escape a keyword? Why do you
> as programmer insist on the use of a keyword? Why do you
> insist that your property is called 'unit'? It's just
> obfuscating the code. With this you can mangle your code completely...
On Tue, 23 Jan 2007, Daniël Mantione wrote:
>
>
> Op Tue, 23 Jan 2007, schreef Michael Van Canneyt:
>
> > I think this goes against all that pascal stands for. We don't want to
> > butcher the language. Next thing you'll be asking to have it case sensitive.
> > As a programmer you know that c
Op Tue, 23 Jan 2007, schreef Michael Van Canneyt:
> I think this goes against all that pascal stands for. We don't want to
> butcher the language. Next thing you'll be asking to have it case sensitive.
> As a programmer you know that certain keywords are keywords. Don't use them
> in your fields
On Tue, 23 Jan 2007, Thorsten Engler wrote:
> While playing around with the compiler source to familiarize myself I've
> produced the attached patch. While I didn't set out to produce anything for
> inclusion into the official codebase at least some of the changes might be
> generally useful.
>
I'm very against this (especially in mode objfpc), and I don't get the
point at all.
In my opinion we have to keep the language as clean as possible.
What could be a rood reason to escape a keyword? Why do you as
programmer insist on the use of a keyword? Why do you insist that your
property is c
37 matches
Mail list logo
