Ticket #918 (closed cage: done)

Opened 12 years ago

Last modified 12 years ago

Change handling of class_init functions

Reported by: NotFound Owned by: NotFound
Priority: minor Milestone:
Component: pmc2c Version: 1.4.0
Severity: low Keywords: deprecate
Cc: Language:
Patch status: Platform:

Description (last modified by NotFound) (diff)

The class_init functions from pmc and dynpmc are inserted in line into the generated class+init that does internal work. This way exposes undocumented variables to the user class_init, which is confusing.

The attached patch shows the proposed change: put the code in a static function and call that function from the generated class_init.

The only problem is that dynpmc from external modules or languages can still be using the now unneeded 'pass' variable, thus that change may need a deprecation cycle.

Attachments

class_init.patch Download (1.9 KB) - added by NotFound 12 years ago.

Change History

Changed 12 years ago by NotFound

Changed 12 years ago by NotFound

  • description modified (diff)
  • summary changed from Change handling of init_class functions to Change handling of class_init functions

Changed 12 years ago by bacek

+1 for idea. We just need consistent naming of "get_foo" vs "foo" method. May be "emit_foo_function" like "emit_class_init_function" is semantically clear enough?

Changed 12 years ago by NotFound

  • status changed from new to assigned
  • owner set to NotFound
  • component changed from none to pmc2c
  • type changed from RFC to cage
  • keywords deprecate added

Added deprecation notice in r41560

Changed 12 years ago by NotFound

Patch applied in r43710. Waiting for some more resting and feedback before removing the deprecation notice and closing the ticket.

Changed 12 years ago by NotFound

  • status changed from assigned to closed
  • resolution set to done

Removed deprecation notice in r44092, closing ticket.

Note: See TracTickets for help on using tickets.