pygccxml-development

[pygccxml-development] FT -subst_t

[Roman Y. <rom...@gm...>]

Hi. The good new is that I started to work on FT feature. The bad news
is  that I don't agree with a lot of implementation details and
interfaces and this time
we will actually fix them.

Lets start.

subst_t we talked that this class should be implementation details and no one
should derive from it, right?  Hierachy is the wrong way to declare about
implementation details. The solution should be aggregation.

This class has ugly interface. subst_t.__init__ method takes as
parameter list of
block variables names. But when substitute function is called this class looks
for variables in self.__dict__. I don't understand why this should be that way.
I don't understand why this class has such interface that very easy to break.
I don't understand why derived class code_manager_t should have ugly variable
names: ARG_LIST_DEF,  ARG_LIST_TYPES and etc. This is not coding convention
of Py++.

This class uses hard coded \n character. This is a mistake. It should use
 os.linesep character.

code_creators_t class already defines indent function. This function should be
moved to utils package and reused from both places.

I don't understand the substitute method of this class. It defines some logic
according to which this method decidec how to indent the line of code. This
is just wrong. code_manager_t class understands the meaning of the variable,
so it is its respocibility to indent the code.

Without subsitute method this class is pretty useless. I think we
should remove it.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] FT -subst_t

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> I don't understand why derived class code_manager_t should have ugly variable
> names: ARG_LIST_DEF,  ARG_LIST_TYPES and etc. This is not coding convention
> of Py++.

I was using upper case variables for sort of "low level" variables that
are usually initialized by corresponding lower case variables. From the
point of view of the function transformer class these variables can be
regarded as internal variables that the transformers usually don't get
in touch with.
But from the point of view of the code creator these are the variables
that it has to use for substitution.

> This class uses hard coded \n character. This is a mistake. It should use
>  os.linesep character.

Of course, I have no objections if you use os.linesep in your code, but
I just wanted to let you know that it doesn't really make a difference.
The following was executed in a Python shell under Windows:

>>> f=file("delme.txt", "wt")
>>> f.write("\n")
>>> f.close()
>>> file("delme.txt", "rb").read()
'\r\n'

Under Linux the same sequence would result in '\n'. So you see, at least
on Windows and Linux, the string "\n" is properly translated into a
native newline.

As to the rest of your mail, I'd rather like to begin at the top instead
of the bottom and see if we can get to a consensus about the API that
function transformer classes can access. From all your mails about the
topic I take it that the function transformer functionality as you have
it in mind is quite a bit different than what I have implemented. So I
started adding sort of a tutorial that explains how function
transformers are written:
https://realityforge.vrsource.org/view/PyppApi/WritingCustomFunctionTransformers
This is what a user has to know if he wants to write his own transformer
classes using the current implementation (the tutorial is not exhaustive 
though). I have added two example classes that demonstrate some parts of 
the API. I'm assuming that the reader also has a look on the 
corresponding parts in the epydoc manual. If the interface as it is seen 
by the user would be kept intact then, of course, I wouldn't mind if the 
underlying implementation is modified.

By the way, my current situation is that the current version of Py++ can
almost do everything I wanted to have for the Maya bindings 
(unfortunately, I have just noticed that there actually are some pure 
virtual methods in the Maya SDK, so that's what's still missing for me 
to do another release). So during the last week I could actually 
continue developing the bindings which unfortunately left me with less 
time for Py++ (the last couple of changes have just been
bugfixes). In addition to that, meanwhile we have a new version of Maya
and creating the bindings for the new version has highlighted some other
problems with Py++ (namely getting an overview of the differences
between the versions and the generated bindings) which might lead to
some modifications to pypp_api.
Now I'm not sure if I should add the code creator for pure virtual 
members to the existing code (using the existing "implementation 
scheme") or to pypp_api. Knowing that the implementation won't survive 
anyway in function_transformers I'm a bit reluctant to add it there. But 
on the other hand, adding it in pypp_api would probably also require 
some modifications in Py++ as it doesn't allow that sort of flexibility 
yet (maybe I could get around that and replace the code creator nodes 
after that tree has been built, but that would be less efficient than 
adding the right nodes right from the beginning...).

- Matthias -

Re: [pygccxml-development] FT -subst_t

[Roman Y. <rom...@gm...>]

On 10/8/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > I don't understand why derived class code_manager_t should have ugly
variable
> > names: ARG_LIST_DEF,  ARG_LIST_TYPES and etc. This is not coding
convention
> > of Py++.
>
> I was using upper case variables for sort of "low level" variables that
> are usually initialized by corresponding lower case variables.
> From the
> point of view of the function transformer class these variables can be
> regarded as internal variables that the transformers usually don't get
> in touch with.
> But from the point of view of the code creator these are the variables
> that it has to use for substitution.

I don't understand "low level" variables. If I understand the code right
you have these variables and few methods that modifies them, right?
So what is "low level" in this? This pattern is widely used in Py++.

> > This class uses hard coded \n character. This is a mistake. It should
use
> >  os.linesep character.
>
> Of course, I have no objections if you use os.linesep in your code, but
> I just wanted to let you know that it doesn't really make a difference.
> The following was executed in a Python shell under Windows:
>
> >>> f=file("delme.txt", "wt")
> >>> f.write("\n")
> >>> f.close()
> >>> file("delme.txt", "rb").read()
> '\r\n'
>
> Under Linux the same sequence would result in '\n'. So you see, at least
> on Windows and Linux, the string "\n" is properly translated into a
> native newline.

You are using here universal line separator. First of I read somewhere
that this feature will be deprecated. Second in next release Py++
will write text files using "codecs" module. This should be done
in order to introduce documentation in different encodings.
I could be wrong, but this module opens files in a binary mode, so this
code will not work.

> As to the rest of your mail, I'd rather like to begin at the top instead
> of the bottom and see if we can get to a consensus about the API that
> function transformer classes can access.

I read the rest of the mail. Trust me, I understand your idea.
Please answer the question I post in the initial mail.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] FT -subst_t

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> On 10/8/06, Matthias Baas <ba...@ir... <mailto:ba...@ir...>> wrote:
>  > Roman Yakovenko wrote:
>  > > I don't understand why derived class code_manager_t should have 
> ugly variable
>  > > names: ARG_LIST_DEF,  ARG_LIST_TYPES and etc. This is not coding 
> convention
>  > > of Py++.
>  >
>  > I was using upper case variables for sort of "low level" variables that
>  > are usually initialized by corresponding lower case variables.
>  > From the
>  > point of view of the function transformer class these variables can be
>  > regarded as internal variables that the transformers usually don't get
>  > in touch with.
>  > But from the point of view of the code creator these are the variables
>  > that it has to use for substitution.
> 
> I don't understand "low level" variables. If I understand the code right
> you have these variables and few methods that modifies them, right?
> So what is "low level" in this? This pattern is widely used in Py++.

Well, with "low level" I just meant that they are 1) always of type 
string and used directly for substitution and 2) that the function 
transformers will usually not manipulate those variables directly.

>  > As to the rest of your mail, I'd rather like to begin at the top instead
>  > of the bottom and see if we can get to a consensus about the API that
>  > function transformer classes can access.
> 
> I read the rest of the mail. Trust me, I understand your idea.
> Please answer the question I post in the initial mail.

I just went over it again and actually you're only making comments 
instead of posing questions. So, erm, there's actually nothing to 
answer... ;) Please rephrase any questions that are important for you to 
move the functionality forward.

- Matthias -

Re: [pygccxml-development] FT -subst_t

[Roman Y. <rom...@gm...>]

On 10/10/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > On 10/8/06, Matthias Baas <ba...@ir... <mailto:ba...@ir...>> wrote:
> >  > Roman Yakovenko wrote:
> >  > > I don't understand why derived class code_manager_t should have
> > ugly variable
> >  > > names: ARG_LIST_DEF,  ARG_LIST_TYPES and etc. This is not coding
> > convention
> >  > > of Py++.
> >  >
> >  > I was using upper case variables for sort of "low level" variables that
> >  > are usually initialized by corresponding lower case variables.
> >  > From the
> >  > point of view of the function transformer class these variables can be
> >  > regarded as internal variables that the transformers usually don't get
> >  > in touch with.
> >  > But from the point of view of the code creator these are the variables
> >  > that it has to use for substitution.
> >
> > I don't understand "low level" variables. If I understand the code right
> > you have these variables and few methods that modifies them, right?
> > So what is "low level" in this? This pattern is widely used in Py++.
>
> Well, with "low level" I just meant that they are 1) always of type
> string and used directly for substitution and 2) that the function
> transformers will usually not manipulate those variables directly.

I will post about this in different thread.

> I just went over it again and actually you're only making comments
> instead of posing questions. So, erm, there's actually nothing to
> answer... ;) Please rephrase any questions that are important for you to
> move the functionality forward.

Fair enough.

I propose to delete subst_t class. Main reason:
Method substitute defines some logic, according to which this it decides how to
indent the code. This is just wrong. code_manager_t class understands
the meaning of
the variables, so it is its respocibility to indent the code. Without
subsitute method this
class is pretty useless.

Do you agree with me?

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] FT -subst_t

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> I propose to delete subst_t class. Main reason:
> Method substitute defines some logic, according to which this it decides how to
> indent the code. This is just wrong. code_manager_t class understands
> the meaning of
> the variables, so it is its respocibility to indent the code. Without
> subsitute method this class is pretty useless.

This proposal doesn't mention how to get back the actual functionality 
after removing subst_t. So I take it you suggest to move the 
substitute() method into the code_manager_t class?

- Matthias -

Re: [pygccxml-development] FT -subst_t

[Roman Y. <rom...@gm...>]

On 10/10/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > I propose to delete subst_t class. Main reason:
> > Method substitute defines some logic, according to which this it decides how to
> > indent the code. This is just wrong. code_manager_t class understands
> > the meaning of
> > the variables, so it is its respocibility to indent the code. Without
> > subsitute method this class is pretty useless.
>
> This proposal doesn't mention how to get back the actual functionality
> after removing subst_t. So I take it you suggest to move the
> substitute() method into the code_manager_t class?

Yes. code_manager_t class understands the variables, so it is its responsibility
to indent them.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] FT -subst_t

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
>> > I propose to delete subst_t class. Main reason:
>> > Method substitute defines some logic, according to which this it 
>> decides how to
>> > indent the code. This is just wrong. code_manager_t class understands
>> > the meaning of
>> > the variables, so it is its respocibility to indent the code. Without
>> > subsitute method this class is pretty useless.
>>
>> This proposal doesn't mention how to get back the actual functionality
>> after removing subst_t. So I take it you suggest to move the
>> substitute() method into the code_manager_t class?
> 
> Yes. code_manager_t class understands the variables, so it is its 
> responsibility
> to indent them.

Well, personally I don't see any advantage or benefit of doing this 
change as the resulting code will behave just the same as before and as 
I said already, this is an internal and minor detail of the package that 
the user will never get in touch with anyway. The implementations would 
be more or less equivalent. So why spending precious time modifying 
internal code that works already? I think we've already wasted too much 
time discussing this detail anyway, so as it obviously has a much higher 
importance to you I'd simply suggest you go ahead with the modification. 
As long as the package works as before I don't mind how the internals 
are implemented.

- Matthias -

Re: [pygccxml-development] FT -subst_t

[Roman Y. <rom...@gm...>]

On 10/11/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> > I propose to delete subst_t class. Main reason:
> >> > Method substitute defines some logic, according to which this it
> >> decides how to
> >> > indent the code. This is just wrong. code_manager_t class understands
> >> > the meaning of
> >> > the variables, so it is its respocibility to indent the code. Without
> >> > subsitute method this class is pretty useless.
> >>
> >> This proposal doesn't mention how to get back the actual functionality
> >> after removing subst_t. So I take it you suggest to move the
> >> substitute() method into the code_manager_t class?
> >
> > Yes. code_manager_t class understands the variables, so it is its
> > responsibility
> > to indent them.
>
> Well, personally I don't see any advantage or benefit of doing this
> change as the resulting code will behave just the same as before

It makes the difference what class formats the code: the one that actually
understands the code, or another, which uses some tricky logic, that envolves
parsing and using regular expression.

> The implementations would be more or less equivalent.

No.

> So why spending precious time modifying
> internal code that works already? I think we've already wasted too much
> time discussing this detail anyway, so as it obviously has a much higher
> importance to you I'd simply suggest you go ahead with the modification.
> As long as the package works as before I don't mind how the internals
> are implemented.

Okey.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/