WARNING: it won't be simple

I'm using visitor pattern in my project and to the best of my knowledge, the visitor should be implemented as an interface. After everything goes compiled, I found out a weird behavior. That is, all the change during accept-visit is gone after control goes back to the initiator (first accept). Even worse, I can't free the object! It causes access violation.

I attach the project that shows this. The project is quite big, but you can focus to only two units (more precisely, to their interface as seen in the attached diff): ast and cg. I create two versions of both units (the other using class with abstract methods) and their diff is attached. Try compiling with both versions (by renaming the one you want to compile to the right name, e.g. without .tmp suffix). Ensure linguc.lpr on line 118 is commented when you're using the interface version (it causes access violation as I state above).

Attachment:
http://free-pascal-general.1045716.n5.nabble.com/file/n3353651/intf.zip intf.zip

Why ?
tiOPF uses the visitor pattern extensively, and it is implemented as a class.

It doesn't compile for me. What version of FPC did you use ?

home: >fpc linguc.lpr
ast.pp(529,19) Error: Cannot find an enumerator for the type "TFPGObjectList$TASTVarDecl"
ast.pp(531,15) Error: Cannot find an enumerator for the type "TFPGObjectList$TASTStatement"
ast.pp(540,19) Error: Cannot find an enumerator for the type "TFPGObjectList$TASTVarDecl"
ast.pp(542,15) Error: Cannot find an enumerator for the type "TFPGObjectList$TASTStatement"
ast.pp(568,16) Error: Cannot find an enumerator for the type "TFPGObjectList$TASTVarDecl"
ast.pp(623,15) Error: Cannot find an enumerator for the type "TFPGObjectList$TASTMethod"
ast.pp(632,15) Error: Cannot find an enumerator for the type "TFPGObjectList$TASTMethod"
ast.pp(651,14) Error: Cannot find an enumerator for the type "TFPGObjectList$TASTClass"
ast.pp(659,14) Error: Cannot find an enumerator for the type "TFPGObjectList$TASTClass"
ast.pp(676) Fatal: There were 9 errors compiling module, stopping
Fatal: Compilation aborted
Error: /usr/local/bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled)

Michael.

Why ? tiOPF uses the visitor pattern extensively, and it is implemented as a class.

Well... because there's only a bunch of visit method which is abstract?

It doesn't compile for me. What version of FPC did you use ?

Whoops! Sorry, I should've said that I use FPC 2.5.1 r16638 (or whatever revision where TFPGObjectList in fgl.pp has enumerator to be used by for-in loop)

What's wrong with using an abstract class ? By choosing an interface, you implicitly get the reference counting on top of things, and this seems to be what causes your error ? (at least, your error is a typical symptom for such cases).

I'll need to update my compiler first, then.

Michael.

In our previous episode, Michael Van Canneyt said:

Why does one need MI in general?

Typically when your items already inherit from an existing class (tpersistent, tcollectionitem or whatever).

What's wrong with using an abstract class ?

Nothing, that's just the way I got taught and I couldn't find a way to say it was wrong until today (I never used interface previously).

By choosing an interface, you implicitly get the reference counting on top of things, and this seems to be what causes your error ?

Yeah, I thought so. There's something different about Object Pascal's interface (I hope Delphi does the same) and Java (the one I learned in college).

You can force more 'Java Compatible' behaviour, I suspect, by choosing CORBA interfaces.

Please try adding

{$INTERFACES CORBA}

Before your interface declaration. It should then skip the reference counting. So if the problem then goes away, you know that the ref. counting was the problem.

Michael.

You can force more 'Java Compatible' behaviour, I suspect, by choosing

CORBA interfaces.

So if the problem then goes away, you know that the ref. counting was the problem.

Yup, that's indeed the problem. I forgot that FPC's interface defaults to COM as in Delphi while Java uses CORBA. Thanks, problem solved.

Michael Van Canneyt kirjoitti sunnuntai 23 tammikuu 2011 17:41:13:

Is this visitor pattern something that I should care about? I have programmed quite much and never needed it.

I found many Java examples from internet and they all were good examples of "over-engineering" IMO. A simple thing made complicated. Virtual methods or method references (kind of event handlers) solve those cases in a cleaner way.

Guess I need to study tiOPF finally. It is on my ToDo list anyway.

Juha

You don't need to care about it. It's a pattern like any other.

Well, visitors have their uses, but I wouldn't overstate their usefulness. Use the right tool for the job, I'd say. :-)

Michael.

I'm writing a compiler. Using visitor pattern it's damn easy to add more backends, such as pretty printer, interpreter, etc.

In our previous episode, said:

(and the GoF, the authors of the book that initiated the pattern movement warn against over use. They wanted to provide a common jargon and write down common experiences for others to mine for ideas, not to tell you what to do. Read their introduction, it is interesting)

Op 2011-01-23 18:43, leledumbo het geskryf:

I must add, I also think the FPC Interfaces should NOT default to COM, because that is just one platform (Windows) out of many that FPC supports. Many developers that use Interfaces, simply don't need or want the memory management that comes default. Thus defaulting FPC's interfaces to a pure language feature (thus no extras like COM or memory management - meaning using CORBA style as default) seems a lot more logical to me.

Regards,
- Graeme -

Hmm... maybe Delphi compatibility has higher priority

Op 2011-01-24 12:35, Juha Manninen het geskryf:

Is this visitor pattern something that I should care about? I have programmed quite much and never needed it.

The Visitor pattern is extremely handy. tiOPF use in for so much, from find objects, changing properties over many objects, processing what objects need to be loaded or saved to/from a persistence layer etc...

Guess I need to study tiOPF finally. It is on my ToDo list anyway.

tiOPF was designed for Object Persistence, but it has grown to have so many nice features and utilities, I find myself often using the base classes (or some other features like Logging) of tiOPF for non-db projects too.

Regards,
- Graeme -

Op 2011-01-28 10:00, leledumbo het geskryf:

Hmm... maybe Delphi compatibility has higher priority

Dictatorship was never a good thing... ;-)

Regards,
- Graeme -

leledumbo wrote

Hmm... maybe Delphi compatibility has higher priority

It could be done mode dependant:
mode Delphi: COM interfaces
mode ObjFPC: CORBA interfaces

(I don't know how that interferes with backwards compatibility in RTL, FCL and LCL though)

Regards,
Sven