Re: [fpc-pascal] A better way?

> On Apr 15, 2016, at 7:03 PM, Sven Barth wrote: > > Again, you're fighting against design principles of the language. It's just > as if you'd want to have virtual class methods in C++… Agreed. Everyone has their own list of things they want their language to do I

Re: [fpc-pascal] A better way?

Am 15.04.2016 13:58 schrieb "Ryan Joseph" : > > > > On Apr 15, 2016, at 5:13 PM, Tony Whyman wrote: > > > > unit unitA; > > > > interface > > > > type > > > > class TClassA > > private > > FClassBObject: TObject; > > public > >

Re: [fpc-pascal] A better way?

Am 15.04.2016 11:22 schrieb "Dennis" : > > >> > You could describe it as typecast done in the var clause of a method. The right hand identifier is not restricted to function parameters. >> >> While it works using "absolute" for a public API is rather unsafe (I'd only use

Re: [fpc-pascal] A better way?

> On Apr 15, 2016, at 5:13 PM, Tony Whyman > wrote: > > unit unitA; > > interface > > type > > class TClassA > private > FClassBObject: TObject; > public > procedure SomeProc; > end; > > implementation > > uses unitB; > > procedure TClassA.SomeProc; >

Re: [fpc-pascal] A better way?

> On Apr 15, 2016, at 6:26 PM, Ryan Joseph wrote: > > I remember trying to doing pre-parser type things using macros but the think > the conclusion is they don’t work by just replace text like in C. > > I’m trying an example like this but getting errors and even

Re: [fpc-pascal] A better way?

> On Apr 15, 2016, at 5:34 PM, Tony Whyman > wrote: > > Just remembered, FPC also supports macros - see > http://www.freepascal.org/docs-html/prog/progse5.html > > I haven't tested it, but you should be able to do > > {$MACRO On} > > {$DEFINE

Re: [fpc-pascal] A better way?

Just remembered, FPC also supports macros - see http://www.freepascal.org/docs-html/prog/progse5.html I haven't tested it, but you should be able to do {$MACRO On} {$DEFINE aClassBObject:=TClassB(FClassBObject) } and then use aClassBObject instead of the coercion. On 15/04/16 11:13, Tony

Re: [fpc-pascal] A better way?

On 15/04/16 10:00, Ryan Joseph wrote: So, a common scenario is a member variable being declared as TObject then having to typecast it every time I need to access one of it’s methods. Declaring another variable in each function instead of typecasting is perhaps more work but maybe I’m not

Re: [fpc-pascal] A better way?

> On Apr 15, 2016, at 3:56 PM, Sven Barth wrote: > > *shudders* Before we introduce such syntax I'd prefer to get the formal class > types that were added for Objective Pascal working with Object Pascal as well > (which would be exactly what you want just with a

Re: [fpc-pascal] A better way?

> On Apr 15, 2016, at 3:46 PM, Tony Whyman > wrote: > > You could describe it as typecast done in the var clause of a method. The > right hand identifier is not restricted to function parameters. I’m not understanding how this would work. I’ve read that the

Re: [fpc-pascal] A better way?

> You could describe it as typecast done in the var clause of a method. The right hand identifier is not restricted to function parameters. While it works using "absolute" for a public API is rather unsafe (I'd only use that in private methods). In those cases the "as" operator should he

Re: [fpc-pascal] A better way?

Am 15.04.2016 08:46 schrieb "Ryan Joseph" : > Does this look like more work than using $includes? Maybe I need to seriously considering reorganizing my projects to work like this but it just feels wrong for some reason. > > = > > unit Globals; >

Re: [fpc-pascal] A better way?

Am 15.04.2016 10:46 schrieb "Tony Whyman" : > > Ryan, > > If you want to get rid of (ugly) typecasts then maybe you should investigate the "absolute" keyword. You get a lot of examples in the LCL. For example, here's one I chose at random: > > function

Re: [fpc-pascal] A better way?

Ryan, If you want to get rid of (ugly) typecasts then maybe you should investigate the "absolute" keyword. You get a lot of examples in the LCL. For example, here's one I chose at random: function TGtk2WidgetSet.RawImage_CreateBitmaps(const ARawImage: TRawImage; out ABitmap, AMask:

Re: [fpc-pascal] A better way?

On 2016-04-15 07:15, Ryan Joseph wrote: > Sure you could put those all in file for this example but in the real > world there may be dozens of TClassB subclasses which would make the > unit 10,000’s of lines long and impossible to navigate. Big units have never been a problem to navigate for me.

Re: [fpc-pascal] A better way?

I’ve cleaned up some code by declaring uses in the implementation and using generic untyped variables like TObject for parameters. This compiles but I’m left with lots of ugly type casting in the implementation because the parameters for methods are untyped. Yes it works but I feel like the

Re: [fpc-pascal] A better way?

> On Apr 15, 2016, at 1:23 AM, Ewald wrote: > > Mutually exclusive classes are mutually exclusive to classes which have > dependencies on one another ;-) > > Or am I missing something? In the example I gave TClassB may be used by many other units but TClassA is only

Re: [fpc-pascal] A better way?

On 14/04/16 16:46, Ryan Joseph wrote: > I think I prefer using type casting or abstract classes more than mixing 2 > mutually exclusive classes into one unit even though they may have > dependancies on each other. Editing and navigating the files would be > confusing for one since there’s no

Re: [fpc-pascal] A better way?

Am 14.04.2016 um 16:25 schrieb Michael Van Canneyt: >> >> That would be a solution but it’s not very pretty. Having 2 classes in the >> same unit that need knowledge of each other but are still mutually >> exclusive is also bad design in my opinion. > > Each is entitled to his opinion. > >

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 9:25 PM, Michael Van Canneyt > wrote: > > In this case the tool tells you that the 2 classes should be in 1 unit. > So, you can waste your time looking for a way out, or just use the tool as > it is meant. I think I prefer using type casting or

Re: [fpc-pascal] A better way?

On Thu, 14 Apr 2016, Ryan Joseph wrote: On Apr 14, 2016, at 6:09 PM, Michael Van Canneyt wrote: So, put bluntly, you are unwilling to do things properly, and then complain that the language does not allow you to do this easily enough ? No, you need to do things

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 6:09 PM, Michael Van Canneyt > wrote: > > So, put bluntly, you are unwilling to do things properly, and then complain > that the > language does not allow you to do this easily enough ? > > No, you need to do things properly. I thought that was

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 5:51 PM, Tony Whyman > wrote: > > unit unitA; > > interface > > type > > class TClassA > private > FClassBObject: TObject; > public > procedure SomeProc; > end; > > implementation > > uses unitB; > > Maybe I’m doing something stupid

Re: [fpc-pascal] A better way?

On Thu, 14 Apr 2016, Ryan Joseph wrote: On Apr 14, 2016, at 5:00 PM, Michael Van Canneyt wrote: You should not need TClassB here. You defeat the point of using an interface. I’m using the interface for specific communication I want denoted in the interface but

Re: [fpc-pascal] A better way?

Ryan, Maybe I’m doing something stupid but other languages have forward declarations so I wonder why Pascal isn’t doing this also since it seems like the obvious solution. Pascal does have forward declarations e.g. class TClassB; class TClassA private FClassBObject: TClassB; end; class

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 5:00 PM, Michael Van Canneyt > wrote: > > You should not need TClassB here. You defeat the point of using an > interface. I’m using the interface for specific communication I want denoted in the interface but I’m still typically using properties

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 4:14 PM, Sven Barth wrote: > > When was Delphi 3 released? Before '96? In that case it would indeed be more > than 20 years ;) I was using CodeWarrior back then (coming from a Mac background) and I didn’t switch to FPC until 2004 maybe. It

Re: [fpc-pascal] A better way?

On Thu, 14 Apr 2016, Ryan Joseph wrote: On Apr 14, 2016, at 2:56 PM, Graeme Geldenhuys wrote: If you can give an actual example we can help. I've used TP then Delphi and now Free Pascal for more than 20+ years. I can probably count on one hand how many

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 2:56 PM, Graeme Geldenhuys > wrote: > > If you can give an actual example we can help. I've used TP then Delphi > and now Free Pascal for more than 20+ years. I can probably count on one > hand how many circular reference issues I had. So I

Re: [fpc-pascal] A better way?

Am 14.04.2016 10:45 schrieb "Ryan Joseph" : > > > > On Apr 14, 2016, at 3:02 PM, Tony Whyman wrote: > > > > Reading through your post, I hope that you are aware that most circular dependencies can be avoided by referencing other units

Re: [fpc-pascal] A better way?

> On Apr 14, 2016, at 3:02 PM, Tony Whyman > wrote: > > Reading through your post, I hope that you are aware that most circular > dependencies can be avoided by referencing other units from the "uses" clause > in the "implementation" section and keeping the

Re: [fpc-pascal] A better way?

Ryan, Reading through your post, I hope that you are aware that most circular dependencies can be avoided by referencing other units from the "uses" clause in the "implementation" section and keeping the "uses" clauses in "interfaces" down to those references strictly necessary for the unit's

Re: [fpc-pascal] A better way?

On 2016-04-14 05:29, Ryan Joseph wrote: > The most annoying problem I have with Pascal currently is with > circular unit dependanices and “global” If you can give an actual example we can help. I've used TP then Delphi and now Free Pascal for more than 20+ years. I can probably count on one hand

[fpc-pascal] A better way?

The most annoying problem I have with Pascal currently is with circular unit dependanices and “global” classes that need to be referenced from many units. In other languages I would make a forward declaration of the class in one file then implement it in another file so that all files could