The first thing I see is the create method in Delphi doesn't require any parameters......(I'm in delphi 5 BTW) Shane

>> 12/20/99 01:01PM >>>

Shane Miller wrote

Also, the declaration for TBITS is not compatable with the Delphi declaration of TBITS. Can this be fixed?

In what way isn't it compatible????

It should be totally compatible with the regular TBits it just has extra features that Delphi doesn't have.

I wrote this one so let me know what you think is wrong with it.

TREct is defined as
TRect = record
   left, top, right, bottom : integer;
end;

I also neeed the topleft and bottomright options for trect.

Can we get that changed?

Thanks
Shane

IMHO, we can get the best of both world. Just make two create methode with overloading. That keep the way it is and be compatible with actual Delphi!

Vital Tremblay

Also, the declaration for TBITS is not compatable with the Delphi declaration of TBITS. Can this be fixed? Shane

>> 12/20/99 12:14PM >>>

TREct is defined as
TRect = record
   left, top, right, bottom : integer;
end;

I also neeed the topleft and bottomright options for trect.

Can we get that changed?

Thanks
Shane

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Shane Miller wrote

The first thing I see is the create method in Delphi doesn't require any parameters......(I'm in delphi 5 BTW)

OK. Your correct. I did write it so that you could pass it a value to set the size of the bits required. I suppose it could be removed. Originally I wrote it as an extra independent class which MVC later incorporated into the standard TBits class. Being able to pass the initial value of the array required seems to be more efficient to me than the way Borland did it.

So this begs the question. Even if something can be done better and more logically are we going to always write it to match Delphi?

Then my next question is, which VCL do we match? In this case TBits is the same since at least Delphi 3 (as far back as I checked) but what if it was different from 3 to 5? Which version do we emulate?

I have no problem removing the create parameter in the TBits class it has just brought up the issues is all.

I have asked this before. Are we building a total Delphi clone or are we building a Delphi like tool?

Opinions.

Shane Miller wrote

Also, the declaration for TBITS is not compatable with the Delphi declaration of TBITS. Can this be fixed?

In what way isn't it compatible????

It should be totally compatible with the regular TBits it just has extra features that Delphi doesn't have.

I wrote this one so let me know what you think is wrong with it.

+ -----Original Message-----
+ From: Kevin Berry
+
+ But TMyFunc isn't just a pointer, it is a type that is
+ a function returning an integer. Correct me if I'm
+ wrong here...

Thats correct.

+ I can't verify this with FPC at the
+ moment.

If you say that the @ operator just returns a untyped pointer then assinging to MyVar (:TMyFunc) is assigning a Pointer to MyVar.

+ Even though you are taking the address of the function
+ (and thus returning a pointer) surely the compiler
+ doesn't just assign any pointer value to the var of
+ type TMyFunc. You'd end up with a rather nasty crash
+ if it allowed you to assign any address to the
+ function variable and then called that function.

That was my point. Ether you do type checking or you don't. If you do it sometimes it is even more confusing than where this thread was about.

Marc

No, you can write compatibility routines. Just make a normal constructor as well, which does the same, but that uses a default size.

I have the streaming system pretty much set up. From the start it will be more general than Delphi's, but it emulates Delphi's system perfectly. (Well, the 'perfectly' remains to be seen of course :) )

Then my next question is, which VCL do we match? In this case TBits is the same since at least Delphi 3 (as far back as I checked) but what if it was different from 3 to 5? Which version do we emulate?

Is that important to you ? Try to make the latest possible; in any case the interface changes between D3 and D5 are almost nihil; the internal stuff changes probably quite a lot.

Delphi like, but as close as possible to the original :-)

If you make improvements, include them, but always include wrapper methods that make existing code still run.

Michael.

+ From: Behalf Of
+
+ On Mon, 20 Dec 1999, Michael A. Hess wrote:
+
+ > That is up to the compiler guys. MVC or Peter is there a reason why
+ > Delphi mode can't do overloading?
+
+ No, we intend to implement the 'overload' switch for Delphi as well;
+ in FPC it's possible to use the overloading without switch,
+ that's all.
+
+ Open Brackets: (
+
+ Although there is a problem with overloading and default parameters
+ in Delphi (see the 'known issues' text that comes with Delphi 5) +
+ Given the declaration:
+
+ Procedure TMyObject.Proc(Param1 : longint; Param2 : Longint
+ default 0);overload;
+ Procedure TMyObject.Proc(Param1 : longint); overload; +
+ And the call:
+
+ MyObj.Proc(2);
+
+ Which one must be called ? Both are legal targets so to speak !
+ The idea of default parameters is as stupid as Visual Basic itself!

Hmm... with overloading yes. See it as a kind of primitive overloading at the time overloading wasn't available in Delphi. These days I think the default parameter shouldn't be used anymore.

+ So this would be a reason for me not implement either
+ overloading either
+ default parameters. (the latter actually)
+
+ ) Close Brackets
+
+ BUT
+ ---
+
+ It seems to me you forget that there is the OBJFPC mode:
+ (command switch -S2 or directive {$MODE OBJFPC}) +
+ This switches on Object Pascal (i.e. classes, exceptions and so on)
+ but is more FPC oriented. The only practical difference is that you
+ should use the address operator when assigning to procedural
+ variables.

Most units are compiled with {$MODE OBJFPC} the only incompatible with delphi is the way to assign eventhandlers (and other procs)

+ I would recommend writing ALL code with that - unless you
+ want your code to
+ be compilable with Delphi as well, in which case you're in
+ trouble with this
+ switch.

IMHO we want the code compatible as wel, in term of porting existing code. Just look at the MWE_FPC switches in mwCustomEdit

+ In the case of TBits, you can just implement 2 constructors:
+
+ Constructor TBits.Create;
+ Constructor TBIts.CreateSized(BitSize : Longint);

Is a way to go...

Marc

Well then, considering that Delphi, now, have implementation of overloading, what about to intend to modify the $MODE DELPHI switch so that overloading still be possible. That should'n cause compatibity probleme IMHO.

Vital Tremblay

mmmm... just thought of something...
Because " MyVar: TMyFunc;" is present wouldn't
it still do type-checking anyway.

_________________________________________________________________

__________________________________________________ Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com

Me too, with the caveat that we try to provide come compatibility calls.

Aha... I was unaware of this. the FCL is made with OBJPAS mode :-)

As long as we can restrict this to a minimum, I'm all for the 'Delphi like'

Understood.

Michael.

Can we get the objfpc mode to allow us NOT to use the @ when assigning procedures? That's the only problem I have seenwith this mode. Shane

>> 12/21/99 02:03AM >>>

No, we intend to implement the 'overload' switch for Delphi as well;
in FPC it's possible to use the overloading without switch, that's all.

Open Brackets: (

Although there is a problem with overloading and default parameters in Delphi (see the 'known issues' text that comes with Delphi 5)

Given the declaration:

Procedure TMyObject.Proc(Param1 : longint; Param2 : Longint default 0);overload;
Procedure TMyObject.Proc(Param1 : longint); overload;

And the call:

MyObj.Proc(2);

Which one must be called ? Both are legal targets so to speak ! The idea of default parameters is as stupid as Visual Basic itself!

So this would be a reason for me not implement either overloading either default parameters. (the latter actually)

) Close Brackets

BUT
---

It seems to me you forget that there is the OBJFPC mode: (command switch -S2 or directive {$MODE OBJFPC})

This switches on Object Pascal (i.e. classes, exceptions and so on) but is more FPC oriented. The only practical difference is that you should use the address operator when assigning to procedural variables.

I would recommend writing ALL code with that - unless you want your code to be compilable with Delphi as well, in which case you're in trouble with this switch.

In the case of TBits, you can just implement 2 constructors:

Constructor TBits.Create;
Constructor TBIts.CreateSized(BitSize : Longint);

Michael.

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

+ From: Kevin Berry
+
+ mmmm... just thought of something...
+ Because " MyVar: TMyFunc;" is present wouldn't
+ it still do type-checking anyway.

Ok... I'm not into the compiler internals, but if I'm correct, if you have an untyped pointer, it is just a pointer and the compiler shouldn't (can't) do typechecking anything else then if it is correct to asign a plain pointer.

Marc

+ --- Kevin Berry wrote:
+ > OUCH! You have a good point...
+ > I'd agree with you that using the typing is better,
+ > then at least the compiler can pick up the type
+ > mismatch.
+ >
+ > --- Marc Weustink wrote:
+ > > Thinking of this brought me to a drawback on using
+ > > the @ operator.
+ > > Depending on the $T (or $TYPEDADDRESS) flag the
+ > > result of the @ operator is
+ > > typed or untyped. In most cases you use untyped
+ > > pointers (?). This means
+ > > that the following is correct
+ > >
+ > > type
+ > > TMyFunc: function:Integer;
+ > >
+ > > var
+ > > MyVar: TMyFunc;
+ > >
+ > > function MyFunc:Interger;
+ > > function MyOtherFunc: TSomething;
+ > > procedure MyProc;
+ > >
+ > > MyVar := @MyFunc;
+ > > MyVar := @MyOtherFunc; (??)
+ > > MyVar := @MyProc; (??)
+ > >
+ > > Marc

My 2c...

Support a fixed version for now (like Delphi 3- or 4 may be better because some very cool stuff was added to 4 even though it wasn't the most stable release). Don't try and support newer versions if they come out during the development of Lazarus / FPC. Once Lazarus is complete then by all means we could support
multiple emulation modes couldn't we? We just need to have different directives... Above all - we mustn't be trying to aim at a rapidly moving target or we
won't hit anything!

When Lazarus is complete it should support Delphi as much as possible. Once it has established itself it can branch off, that way more people will adopt it.

Kevin.

__________________________________________________ Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com

(can't)

do typechecking anything else then if it is correct to asign a plain pointer. Marc

That's why I say not using @ is better.. that way it's more consistent. If you assign a value to a var, the compiler will make sure that the types are good.. and you can always do a typecast if you want to force it.

type
   TFunc1: function:Integer;
   TFunc2: function:Boolean;
var
    VarFunc1 : TFunc1
    VarFunc2 : TFunc2
    Int:Integer;
function Func1:Interger;
function Func2:Boolean;
VarFunc1:= Func1;
VarFunc2:= Func2;
Int:= VarFunc1;
// ^- that makes perfect sence, right?
Int:= VarFunc2;
// ^- that's not good, right?
VarFunc1:= @Func2;
Int:= VarFunc1;
// ^- then that's no good either....

Or I migh tjust be missing the point.

----- Original Message -----

To clarify things you can write

Int:=VarFunc1();

in FPC (don't flame me for that C like construct).

So I think

;
Int:=VarFunc1();

is very clear, everybody knows what happens without knowing the actual types!!!

Or I migh tjust be missing the point.

One important point is overloading, consider the following:

type
   tf = function : integer;
function f : integer;
procedure p(i : integer);
procedure p(f : tf);

In Delphi mode you would write:

p(f);

but what should the compiler do? Call f and using the first version p or using the second one and passing the address of f?

In FPC mode it's clear:
p(f);
means calling f and using the integer version of p while
p(@f);
calls the second one

It even works if you've a third version of p:
procedure p(p : pointer);
p(@f);

still calls the second version because the last one would require an (implicit) type cast, if you
want to call the last one you have to write

p(pointer(@f));

+ From: Peter Vreman

+ Alexandre Grenier wrote:
+ > I don't find it confusing...
+ >
+ > You create a procedural type.. and then a Var of that
+ type.. and assign it a
+ > value of the same type. Just like you would do with
+ integers.. or strings..
+ > Var:= Value.. so logical.
+ But...
+
+ procedure(function);
+
+ is the result of the function passed or the function as procvar? +
+
+ procedure(procedurevar);
+
+ is the result of the procvar function passed or the procvar itself? +
+ And what if the result of the function is a procvar?

It is pretty clear if you take the following rule into account:

If a function/procedure matches the type of the var, the adress of this function/procedure is passed. In all other cases the evaluation of function/procedure(?).

So in your example MyProc(MyFunc) it depends on the declaration of MyProc and MyFunc. If MyProc expects a MyFunc type then myfunc is passed as procvar otherwise its evaluated.

The same for procedure(procvar).

Thinking of this brought me to a drawback on using the @ operator. Depending on the $T (or $TYPEDADDRESS) flag the result of the @ operator is typed or untyped. In most cases you use untyped pointers (?). This means that the following is correct

type
  TMyFunc: function:Integer;
var
  MyVar: TMyFunc;
function MyFunc:Interger;
function MyOtherFunc: TSomething;
procedure MyProc;
MyVar := @MyFunc;
MyVar := @MyOtherFunc; (??)
MyVar := @MyProc;      (??)

Marc

IMHO, we can get the best of both world. Just make two create methode with overloading. That keep the way it is and be compatible with actual Delphi!

Well given how TBits is written and the fact that it is included in the classes unit we might be able to get away with it in this case.

However please note the following information from in the FPC Manuals. Since most of what we are doing should be using the "$MODE DELPHI" switch this puts a kink in it.

+++++++++++++ From the manuals ++++++++++++++++++

D.3 Delphi mode

This mode is selected by the $MODE DELPHI switch. On the command-line, this mode is selected by the -Sd switch.
1. You can not use the address operator to assign procedural variables.
2. A forward declaration must not be repeated exactly the same by the implementation of a function/procedure. In particular, you can not omit the parameters when implementing the function or procedure.
3. Overloading of functions is not allowed.

+++++++++++++++++++++++++++++++++++++++++++

This wasn't the whole listing, just up to item 3 which is the problem. We can't write in Delphi mode with FPC and use overloading.

But...

procedure(function);

is the result of the function passed or the function as procvar?

procedure(procedurevar);

is the result of the procvar function passed or the procvar itself?

And what if the result of the function is a procvar?

Peter

<snip>

default parameters are on the todo list, but with a very very low priority.

EOT for default paramters for now...

Peter

0);overload;

Compiler should report an error.

The idea of default parameters is as stupid as Visual Basic itself!

No, no, no. At first, default parameters, as I know, came from C++, not from VB (though implementation in Delphi is the best :).

And second, default parameters are VERY convenient. Suppose you need to add one more parameter to function so that all existing calls to this function remain compileable.
Compare this

1.
interface
procedure MyFunction(OneParameter: Integer; OneMoreParameter: Boolean =
False);
...
implementation
procedure MyFunction(OneParameter: Integer; OneMoreParameter: Boolean =
False);
begin
...
end;

and this:

2.
interface
procedure MyFunction(OneParameter: Integer); overload;
procedure MyFunction(OneParameter: Integer; OneMoreParameter: Boolean);
overload;
...
implementation
procedure MyFunction(OneParameter: Integer);
begin
  MyFunction(OneParameter, False);
end;
procedure MyFunction(OneParameter: Integer; OneMoreParameter: Boolean);
begin
  ...
end;

The first is quicker to write and easier to read - you can immediately tell what is the default value for OneMoreParameter without looking through implementation.

So this would be a reason for me not implement either overloading

either

default parameters. (the latter actually)

I see no problem supporting both this and that - as I mentioned, compiler should report an error in conflict situations.

) Close Brackets

That's not completely true. Some D3 code will not compile in D4/D5 without some additional changes. What do we do when D6 comes out? Do we change the LCL so it matches D6? I guess what I am asking is there ever going to be a time when we are going to splinter off and diverge from Delphi? I know we are far from this point yet but when do we start doing things to be the lead in Pascal OOP design and not just a Delphi follower?

But TMyFunc isn't just a pointer, it is a type that is a function returning an integer. Correct me if I'm wrong here... I can't verify this with FPC at the moment.

Even though you are taking the address of the function (and thus returning a pointer) surely the compiler doesn't just assign any pointer value to the var of type TMyFunc. You'd end up with a rather nasty crash if it allowed you to assign any address to the
function variable and then called that function.

BTW, I do prefer the Delphi way of not expecting an @ to be prefixed. The @ prefix reminds me of the way C++ operates with the & operator. I like the way ^ and @ are really optional in Delphi's Object Pascal. I thought it was quite a clever modification they made to the language...

Kevin.

__________________________________________________ Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com

you wrote

Can we get the objfpc mode to allow us NOT to use the @ when assigning procedures? That's the only problem I have seenwith this mode. Shane

Why do you think we implemented the @ for assigning? Because the delphi/tp way is very confusing. So we will NEVER turn it off in objfpc mode ofcourse.

Peter

OUCH! You have a good point...
I'd agree with you that using the typing is better, then at least the compiler can pick up the type
mismatch.

__________________________________________________ Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com

That is up to the compiler guys. MVC or Peter is there a reason why Delphi mode can't do overloading?

<snip>

So this would be a reason for me not implement either overloading either default parameters. (the latter actually)

So if overloading in Delphi mode might not be made available OR the default parameters aren't made available doesn't that make it difficult to make things Delphi portable? This sort of seems to support my question, "Is this to be a Delphi like or Delphi clone?". I support the idea that it is Delphi like.

No I didn't forget it, it is just that it has also been mentioned at various times in this list that we should be using MODE DELPHI since the LCL is suppose to support Delphi. Catch 22.

I would recommend writing ALL code with that - unless you want your code to be compilable with Delphi as well, in which case you're in trouble with this switch.

I believe that is sort of what my question means. Is the code we write in FPC using LCL to be totally compatible with Delphi. I favor the idea that Delphi code will need some modifications to work in FPC. However I don't think that is the idea that others a striving for.

In the case of TBits, you can just implement 2 constructors: Constructor TBits.Create; Constructor TBIts.CreateSized(BitSize : Longint);

Agreed. As I stated before this specific change is minor it just brought up the general problem for me.

I hate to point out the obvious, but...
(see my point below - in reply to this)

--- Florian Klaempfl wrote:
[...snip...]

in Delphi, to clarify your call you simply do the
following:

  p(integer(f));
      it will call procedure "procedure p(i:

integer);"

if you do
p(f)
it will call procedure "procedure p(f : tf);"

You have the best type-checking if you don't convert to a pointer using @. Unless of course you've
proposed changing the normal behaviour of the @
operator so some kind of type-checking is done with function and procedure types??

BTW, I now have Linux up and running on my system and I can dial into the 'net too so I will be doing some Lazarus development work soon...

Kevin.

_________________________________________________________ Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

No, we intend to implement the 'overload' switch for Delphi as well;
in FPC it's possible to use the overloading without switch, that's all.

Open Brackets: (

Although there is a problem with overloading and default parameters in Delphi (see the 'known issues' text that comes with Delphi 5)

Given the declaration:

Procedure TMyObject.Proc(Param1 : longint; Param2 : Longint default 0);overload;
Procedure TMyObject.Proc(Param1 : longint); overload;

And the call:

MyObj.Proc(2);

Which one must be called ? Both are legal targets so to speak ! The idea of default parameters is as stupid as Visual Basic itself!

So this would be a reason for me not implement either overloading either default parameters. (the latter actually)

) Close Brackets

BUT
---

It seems to me you forget that there is the OBJFPC mode: (command switch -S2 or directive {$MODE OBJFPC})

This switches on Object Pascal (i.e. classes, exceptions and so on) but is more FPC oriented. The only practical difference is that you should use the address operator when assigning to procedural variables.

I would recommend writing ALL code with that - unless you want your code to be compilable with Delphi as well, in which case you're in trouble with this switch.

In the case of TBits, you can just implement 2 constructors:

Constructor TBits.Create;
Constructor TBIts.CreateSized(BitSize : Longint);

Michael.

+ From: Florian Klaempfl

<snip>

+
+ One important point is overloading, consider the following: +
+ type
+ tf = function : integer;
+
+ function f : integer;
+ procedure p(i : integer);
+ procedure p(f : tf);
+
+ In Delphi mode you would write:
+
+ p(f);
+
+ but what should the compiler do? Call f and using the first
+ version p or
+ using the second one and passing the address of f?

As I wrote earlier this thread:
It is pretty clear if you take the following rule into account:

If a function/procedure matches the type of the var, the adress of this function/procedure is passed.
In all other cases the evaluation of function/procedure(?).

So in your example procedure p(f : tf) gets called.

Thats the same Delphi does. If you want to get f evaluated you should call p like: p((f)) so f gets evaluated first (bracket rule). Its still clear.

+ In FPC mode it's clear:
+ p(f);
+ means calling f and using the integer version of p
+ while
+ p(@f);
+ calls the second one

+ It even works if you've a third version of p:
+ procedure p(p : pointer);
+
+ p(@f);
+ still calls the second version because the last one would
+ require an (implicit) type cast,
+ if you
+ want to call the last one you have to write
+
+ p(pointer(@f));

??? That is IMHO dependig of the result of the @ operator is typed or untyped (depending on the T derective)

if the @ result is typed, the second form should be called otherwise the third (since it is untyped and thus a Pointer).

If not so then the compiler is IMHO inconsequent (and inclear)

Marc

As I said, make it better wherever possible, and provide compatibility methdos/properties. Existing delphi code will work and compile, although not as efficient as native lcl code.

Michael.

+ From: Florian Klaempfl
+ Marc Weustink wrote:
+ >
+ > <snip>
+ > As I wrote earlier this thread:
+ > It is pretty clear if you take the following rule into
+ > account:
+ >
+ > If a function/procedure matches the type of the var,
+ > the adress of this function/procedure is passed.
+ > In all other cases the evaluation of function/procedure(?). +
+ What about a function returning a procedure variable? Here
+ you get really
+ lost with Delphi :)

No, the rule still applies. If the function matches the function itself is passed otherwise the result. Give me an example where you think it goes wrong and I'll show why not.

+
+ >
+ > So in your example procedure p(f : tf) gets called.
+ >
+ > Thats the same Delphi does. If you want to get f evaluated
+ you should call p
+ > like: p((f)) so f gets evaluated first (bracket rule). Its
+ still clear.
+
+ This is not pascal this is nonsense (to avoid explicit
+ language). A bracket is in this
+ case a syntactical element and it shouldn't change the
+ semantic of an expression!!!!

Sorry this is pascal. It is just like if you want to calculate (1+2) * 3. The expression between brackets gets evaluated first. And for a proper/consequent language it shouldn't matter if you evaluate (1+2) or (f) or (f+f)*2

I don't see where this changes the semantic of the expression.

+ > + p(@f);
+ > + still calls the second version because the last one would
+ > + require an (implicit) type cast,
+ > + if you
+ > + want to call the last one you have to write
+ > +
+ > + p(pointer(@f));
+ >
+ > ??? That is IMHO dependig of the result of the @ operator is
+ > typed or untyped (depending on the T derective) +
+ I'am always assuming @ returns a typed pointer :).

Assuming is a bad thing in this case, the compiler don't warn you if something is not ok ;-)
+
+
+ Besides that, FPC lets choose what you want.

That was the whole point. If you have chosen for an untyped pointer constructions like:

type
  TMyFunc: function:Integer;
var
  MyVar: TMyFunc;
function MyFunc:Interger;
function MyOtherFunc: TSomething;
procedure MyProc;
MyVar := @MyFunc;
MyVar := @MyOtherFunc; (??)
MyVar := @MyProc;      (??)

are still valid. I think in other cases you want untyped pointers, but in this case you never want that.

Marc

What about a function returning a procedure variable? Here you get really lost with Delphi :)

This is not pascal this is nonsense (to avoid explicit language). A bracket is in this case a syntactical element and it shouldn't change the semantic of an expression!!!!

I'am always assuming @ returns a typed pointer :).

Besides that, FPC lets choose what you want.