[lazarus] classesh.inc change required

[michael at tfdec1.fys.kuleuven.ac.be]

On Tue, 21 Dec 1999, Michael A. Hess wrote:

> michael at tfdec1.fys.kuleuven.ac.be wrote:
> > 
> 
> <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.

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

> 
> > BUT
> > ---
> > 
> > It seems to me you forget that there is the OBJFPC mode:
> > (command switch -S2 or directive {$MODE OBJFPC})
> 
> 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. 

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

> 
> > 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.

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

>  
> > 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.

Understood.

Michael.