RE: [pyasn1-users] Decoding enumerated types

[Chui T. <te...@co...>]

Ilya

Thanks for your help. It was only a toy project, and didn't need to meet any
specific business needs. Hopefully it gave pyasn1 a useful workout.  Aside,
could forward declratation be imported through delayed load by name?

class A:
   memberName = "B"
   globals()[memberName]

class B:
   memberName = "A"
   globals()[memberName]

-----Original Message-----
From: Ilya Etingof [mailto:il...@gl...] 
Sent: Wednesday, 29 March 2006 2:52 AM
To: Ilya Etingof
Cc: Chui Tey; pya...@li...
Subject: Re: [pyasn1-users] Decoding enumerated types


[ skipped ]

> Although, I'm somewhat puzzled about the recursive Filter type 
> specification in rfc2251. I'm not sure how to express it in pyasn1... 
> Let me think it over and get back if I ever figure a consistent solution.

Let me beg your pardon for it has taken so long for me to get back to the
recursive definitions issue...

Unfortunately, I don't see a reasonable (meaning not too much hackerish)
solution for it with pyasn1. The basic cause is that pyasn1 types are
intentionally immutable by design and Python doesn't allow forward object
specifications (like C does for instance).

In other words, I don't know how to do stuff like:

class a1:
  member = a2
class a2:
  member = a1

meaning "a2" is referenced before definition what is invalid with Python.

From the other hand, it would be conceptually lame with pyasn1 to hack
pyasn1 object this way:

class a1:
  pass
class a2:
  member = a1
a1.member = a2

for cross referencing them.

That's why the only workaround I can think about at the moment would be to
convert recursion into interation up to certain depth:

class a1:
  member = None
class a2:
  member = a1
class a3:
  member = a2
class a4:
  member = a3
class a:
  member = a4

Let me know if you still need a more practical solution on the issue.

-ilya