> 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
guess. Maybe I got spoiled w
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
> > procedure SomeProc;
> > end;
> >
> > implementation
> >
> > uses uni
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 that in private methods). I
> 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;
> var aClassBObject: TClassB absolute
> 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 crashing the
> compiler (seg f
> 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 aClassBObject:=TClassB(FClassBObject) }
>
> and
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 Why
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 get
> 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 more sane syntax).
I agree 100
> 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 keyword (I’ve
never heard about u
> 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 us
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;
> interface
>
> type
> HCla
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 TGtk2WidgetSet.RawImage_CreateBitmaps(const AR
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: HBitma
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. Y
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 comp
> 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 used with one other unit.
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 obv
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.
>
> Practi
> 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 abstract classes more than
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 properly.
I thought that
> 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 probably the answer I’d g
> 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 but other languages have forward
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 I’m still typically using p
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 T
> 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 of the child class in
ad
> 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 would have been smart to learn
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 circular reference issues I had. So
> 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 dont' think it is
> such a big p
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 from the "uses"
clause in the "implementation" section and keep
> 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 "uses" clauses in
> "interfaces" d
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
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 h
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 ref
34 matches
Mail list logo
