Marko Riedel | 14 Jul 17:30

Gorm class parser.


Hi folks,

I have come across a problem in the classloader of Gorm.app. I ask your understanding when I say it is not
terribly sophisticated. I had noticed that declarations of several instance variables of the same type
like so

NSMutableArray *a1, *a2,

would confuse it, resulting in corrupted outlet lists, so now I always write

NSMutableArray *a1;
NSMutableArray *a2;

Now I have another, more serious problem: it appears that the parser will consider everything an outlet
that contains the string "id", e.g.

NSMutableDictionary *namesToPids;

will cause "namesToPids" to appear in the outlet list. This is an annoying problem and I don't think not to
use the string "id" in variable names is an acceptable solution (though using "namesToPIDs" will fix it).

Anyhow I hope you can replicate this, if not, please accept my apologies.

BTW does GNUstep have a regexp libary yet that offers, say Perl-compatible regular expressions with
different enodings (utf8 ...)?

Best regards,

Marko
(Continue reading)

Marko Riedel | 14 Jul 18:10

Re: Gorm class parser.

Additional comments below.

+-------------------------------------------------------------+
| Marko Riedel, EDV Neue Arbeit gGmbH, markoriedelde <at> yahoo.de |
| http://www.geocities.com/markoriedelde/index.html           |
+-------------------------------------------------------------+

--- Marko Riedel <markoriedelde <at> yahoo.de> schrieb am Mo, 14.7.2008:

> Von: Marko Riedel <markoriedelde <at> yahoo.de>
> Betreff: Gorm class parser.
> An: "DISCUSS GNUstep" <discuss-gnustep <at> gnu.org>
> Datum: Montag, 14. Juli 2008, 17:33
> Hi folks,
> 
> I have come across a problem in the classloader of
> Gorm.app. I ask your understanding when I say it is not
> terribly sophisticated. I had noticed that declarations of
> several instance variables of the same type like so
> 
> NSMutableArray *a1, *a2,
> 
> would confuse it, resulting in corrupted outlet lists, so
> now I always write
> 
> NSMutableArray *a1;
> NSMutableArray *a2;

What I mean here is that declarations like the above in the vicinity of a declaration like

(Continue reading)

Re: Gorm class parser.

The parser I wrote for Gorm is a recursive descent parser and a pretty simple one.   I didn't want to make yacc
and a full up grammer part of Gorm unless I absolutely had to.  Unfortunately it doesn't take the case you
spoke of into account, so it could be a simple matter of adding this to the parser so that it can be handled properly.

Please do me a favor and **WRITE THIS UP AS A BUG** on savannah instead of talking about it here so that it can be
properly tracked.   Also, please send some example header files which you are having this problem with
because I would like to verify that I see the same behavior with the same files rather than taking a guess and
copying from your email.

Regard, GC

 Gregory Casamento -- Principal Consultant - OLC, Inc 
# GNUstep Chief Maintainer

----- Original Message ----
From: Marko Riedel <markoriedelde <at> yahoo.de>
To: DISCUSS GNUstep <discuss-gnustep <at> gnu.org>
Sent: Monday, July 14, 2008 11:33:12 AM
Subject: Gorm class parser.

Hi folks,

I have come across a problem in the classloader of Gorm.app. I ask your understanding when I say it is not
terribly sophisticated. I had noticed that declarations of several instance variables of the same type
like so

NSMutableArray *a1, *a2,

would confuse it, resulting in corrupted outlet lists, so now I always write

(Continue reading)


Gmane