Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2011-01

Nested Classes used as Namespace Issue

11 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Andrew Brunner
type
  ns=class
  Type
     Vendor=class
     Const
       id    = "ITMID';
       Size = 'ITMSIZE';
     Type
        PVendor=^TVendor;
        TVendor=record
          ID : Int64;
          Size : Integer;
        end;
        class procedure Foo();
     end;
     Supplier=class
         // example
        class procedure Foo();
     end;
  end;
end;

Neither ns.Supplier.Foo() nor ns.Vendor.Foo() will not jump to the actual code in Lazarus IDE. It kind of muddles nested classes (as namespaces) that FPC supports. Is this on someones list of todos?

Reply by email

Paul Ishenin
to Andrew Brunner
Andrew Brunner wrote 25 lines
type ns=class Type Vendor=class Const id = "ITMID'; Size = 'ITMSIZE'; Type PVendor=^TVendor; TVendor=record ID : Int64; Size : Integer; end; class procedure Foo(); end; Supplier=class // example class procedure Foo(); end; end; end; Neither ns.Supplier.Foo() nor ns.Vendor.Foo() will not jump to the actual code in Lazarus IDE. It kind of muddles nested classes (as namespaces) that FPC supports. Is this on someones list of todos?

Codetools does not recognise the nested class syntax yet. There was already a feature request.

Best regards,
Paul Ishenin

Reply by email

Razvan Adrian Bogdan
to Andrew Brunner: type ns=class Type Vendor=class Const id = "ITMID'; Size = 'ITMSIZE'; Type…
Andrew Brunner wrote 27 lines
type ns=class Type Vendor=class Const id = "ITMID'; Size = 'ITMSIZE'; Type PVendor=^TVendor; TVendor=record ID : Int64; Size : Integer; end; class procedure Foo(); end; Supplier=class // example class procedure Foo(); end; end; end; Neither ns.Supplier.Foo() nor ns.Vendor.Foo() will not jump to the actual code in Lazarus IDE. It kind of muddles nested classes (as namespaces) that FPC supports. Is this on someones list of todos? Interesting stuff, it's like nested records, but wouldn't this look nicer

if the "type" keyword was optional, maybe only required where there is not keyword like class or record ? This looks like a nice feature but it shouldn't make code less readable by requiring keywords that only make the source more ugly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110110/0ba4e99e/attachment.html>

Reply by email

Sven Barth
to Razvan Adrian Bogdan
Razvan Adrian Bogdan wrote 34 lines
On Mon, Jan 10, 2011 at 6:43 AM, Andrew Brunner < <mailto:>> wrote: type ns=class Type Vendor=class Const id = "ITMID'; Size = 'ITMSIZE'; Type PVendor=^TVendor; TVendor=record ID : Int64; Size : Integer; end; class procedure Foo(); end; Supplier=class // example class procedure Foo(); end; end; end; Neither ns.Supplier.Foo() nor ns.Vendor.Foo() will not jump to the actual code in Lazarus IDE. It kind of muddles nested classes (as namespaces) that FPC supports. Is this on someones list of todos? Interesting stuff, it's like nested records, but wouldn't this look nicer if the "type" keyword was optional, maybe only required where there is not keyword like class or record ? This looks like a nice feature but it shouldn't make code less readable by requiring keywords that only make the source more ugly.

In Pascal all type declarations appear in blocks that are named "type". This is the case in global unit scope, in local method scope and in class scope as well. So I don't think one should brake with the way Pascal works just to create code that looks more beautiful.

And this is also Delphi compatible.

Regards,
Sven

Reply by email

Razvan Adrian Bogdan
to Sven Barth
Sven Barth wrote 6 lines
In Pascal all type declarations appear in blocks that are named "type". This is the case in global unit scope, in local method scope and in class scope as well. So I don't think one should brake with the way Pascal works just to create code that looks more beautiful. And this is also Delphi compatible.

Yes i agree this is indeed how it works, what i meant was: Why not do it the same way the Records work.
You can nest records and you don't use the type keyword for the nested records, the parser/compiler knows how to recognize a "subrecord". By making the type keyword optional you don't break anything and the compiler isn't confused and it is the way records work already and this behavior is much older and cleaner than the way it's implemented now.

 type
   TMyStruct = record
     NestedStruct = record
       SimpleMember: string;
     end;
   end;

Just replace record with class and no type keyword is required, it's simple, clean and not ambiguous in any way. For declaring other types inside the class is would probably require the type keyword just not for nested classes/records.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110111/e04173bc/attachment.html>

Reply by email

Sven Barth
to Razvan Adrian Bogdan
Razvan Adrian Bogdan wrote 27 lines
On Mon, Jan 10, 2011 at 9:48 PM, Sven Barth < <mailto:>> wrote: In Pascal all type declarations appear in blocks that are named "type". This is the case in global unit scope, in local method scope and in class scope as well. So I don't think one should brake with the way Pascal works just to create code that looks more beautiful. And this is also Delphi compatible. Yes i agree this is indeed how it works, what i meant was: Why not do it the same way the Records work. You can nest records and you don't use the type keyword for the nested records, the parser/compiler knows how to recognize a "subrecord". By making the type keyword optional you don't break anything and the compiler isn't confused and it is the way records work already and this behavior is much older and cleaner than the way it's implemented now. type TMyStruct = record NestedStruct = record SimpleMember: string; end; end; Just replace record with class and no type keyword is required, it's simple, clean and not ambiguous in any way. For declaring other types inside the class is would probably require the type keyword just not for nested classes/records.

No, that doesn't work that way in records. You can only have a record field that has a inline defined type, but you can't access that type by its name anywhere (it's something like an anonymous type). You can do that in classes as well by the way (but only with records).

E.g.
type
   TMyStruct = record
     SubStructField: record // <= note the colon
                       SimpleMember: String;
                     end;
   end;
   TMyClass = class
     SubStructField: record
                       Foo: Integer;
                     end;
   end;

Regards,
Sven

Reply by email

Paul Ishenin
to Razvan Adrian Bogdan: Yes i agree this is indeed how it works, what i meant was: Why not do it the same way the…
Razvan Adrian Bogdan wrote 6 lines
type TMyStruct = record NestedStruct = record SimpleMember: string; end; end;

What compiler can compile this type?

Type keyword is requires to disctinct different sections inside structures. In classes, records and object you can have inner type, const, var, class var and method sections.

Best regards,
Paul Ishenin

Reply by email

Razvan Adrian Bogdan
to Paul Ishenin
Paul Ishenin wrote 14 lines
11.01.2011 20:49, Razvan Adrian Bogdan wrote: > type > TMyStruct = record > NestedStruct = record > SimpleMember: string; > end; > end; > What compiler can compile this type? Type keyword is requires to disctinct different sections inside structures. In classes, records and object you can have inner type, const, var, class var and method sections.

Opps sorry for that second "=" symbol, i meant ":" like Sven wrote earlier but with class and yes it would only be visible with that class and a somewhat anonymous class.

" TMyClass = class
SubStructField: record

      Foo: Integer;
   end;

end;"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110111/24b02de9/attachment.html>

Reply by email

Paul Ishenin
to Razvan Adrian Bogdan

11.01.2011 23:40, Razvan Adrian Bogdan ?????:

Show quoted text 29 lines
On Tue, Jan 11, 2011 at 4:18 PM, Paul Ishenin < <mailto:>> wrote: 11.01.2011 20:49, Razvan Adrian Bogdan wrote: type TMyStruct = record NestedStruct = record SimpleMember: string; end; end; What compiler can compile this type? Type keyword is requires to disctinct different sections inside structures. In classes, records and object you can have inner type, const, var, class var and method sections. Opps sorry for that second "=" symbol, i meant ":" like Sven wrote earlier but with class and yes it would only be visible with that class and a somewhat anonymous class. " TMyClass = class SubStructField: record Foo: Integer; end; end;"

Then it is not a nested type but just a regular field which type is defined as anonymouse record. Initially the question was about nested type declaration, not about fields.

Best regards,
Paul Ishenin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110112/45c1aafc/attachment.html>

Reply by email

Mattias Gaertner
to Andrew Brunner: type ns=class Type Vendor=class Const id = "ITMID'; Size = 'ITMSIZE'; Type…
Show quoted text 25 lines
type ns=class Type Vendor=class Const id = "ITMID'; Size = 'ITMSIZE'; Type PVendor=^TVendor; TVendor=record ID : Int64; Size : Integer; end; class procedure Foo(); end; Supplier=class // example class procedure Foo(); end; end; end; Neither ns.Supplier.Foo() nor ns.Vendor.Foo() will not jump to the actual code in Lazarus IDE. It kind of muddles nested classes (as namespaces) that FPC supports. Is this on someones list of todos?

Should work now.

Mattias

Reply by email

Andrew Brunner
to Mattias Gaertner

Hi Mattias,

It sure did! Thanks resolving this issue that fast. It was a major problem for me. Code navigation is important and it was well worth the time. I don't think enough pascal developers realize the "awesomeness" of organizing methods, vars, structs within the context of a class. Thanks again!

Keep up the great work guys!

Reply by email