Naming Conventions in High-Level Encapsulations

Hello Forum,

We're nearly finished with the raw encapsulation of all of the Xtreme
Suite's ActiveX controls, and we were wondering what Smalltalkers expect
in the way of naming conventions.  We ask because we intend to release
our encapsulations into the community in case others wish to use this
incredible product.

For example, the XtremeCommandBars control has a method called
ClosePopups().  The documentation reveals that a better name might be
CloseAllPopups().  Doing things the Smalltalk way would, indeed, imply
that our selector should be #closeAllPopups, the word "All" appearing to
be a common feature in the Smalltalk idiom.

For those of you with experience, would you find it an irritation if our
naming conventions deviated from the control's naming conventions?  Our
thinking is that, once we've reached the stage of high-level
encapsulation, the Smalltalk style should prevail.  But then on the
other hand, if one were trying to map the controls' documentation to our
encapsulation, one might find deviations a hindrance.

Any thoughts?


Cheers,

Eric

Eric,

> For those of you with experience, would you find it an irritation if our
> naming conventions deviated from the control's naming conventions?  Our
> thinking is that, once we've reached the stage of high-level
> encapsulation, the Smalltalk style should prevail.  But then on the
> other hand, if one were trying to map the controls' documentation to our
> encapsulation, one might find deviations a hindrance.

You can approach this the same way OA treats COM: have a potentially
private method for each virtual method and then add wrapper/helper
methods as you see fit.  With the control docs in hand, one can start
from the "primitives" and browse for references to find the wrappers.
You should ensure that anything you write yourself is not in the auto
generated category.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

We're pretty comfortable with the _process_ of wrapping.  We're just not
sure on the naming conventions.

>...have a potentially private method for each virtual method and then
add >wrapper/helper methods as you see fit.

Hmmm.  We'll have to look at this.  I'm sure we'll be refining these
encapsulations as we put them into practice.

Thanks very much.


Cheers,

Eric
our
> > naming conventions deviated from the control's naming conventions?
Our
> > thinking is that, once we've reached the stage of high-level
> > encapsulation, the Smalltalk style should prevail.  But then on the
> > other hand, if one were trying to map the controls' documentation to
our

"Eric Taylor" <[hidden email]> wrote in message
news:001301c68fee$c5f230d0$6500a8c0@server...
Bill is right; the Smalltalk style would be to rename the operations so that
they make sense when spoken as English. The ability to quickly follow
reference chains in the IDE is a core skill in Smalltalk development, so
programmers should be well used to doing this and can easily use that to map
from control documentation to your higher level abstractions. Lastly you'll
find (no doubt have found ) that there are places in any abstraction where
you want to deviate from the underlying control significantly, so to avoid
the "analysis paralysis" of attempting to keep a mapping between the control
documentation and your abstraction, I would just let go of the relationship
entirely and not worry about it :-)

Regards

Blair

Hello Blair,

>you'll find (no doubt have found) that there are places in any
abstraction >where you want to deviate from the underlying control
significantly...

Indeed!  That's what prompted our question :)  Other languages are
beginning to seem antiquated and unexpressive compared to Smalltalk.  We
just wanted to make sure that we could "let go," as you say.

Cheers,

Eric

not
> > sure on the naming conventions.
> >
> >>...have a potentially private method for each virtual method and
then
> > add >wrapper/helper methods as you see fit.
> >
> > Hmmm.  We'll have to look at this.  I'm sure we'll be refining these
> > encapsulations as we put them into practice.
> >
> > Thanks very much.
> >
>
> Bill is right; the Smalltalk style would be to rename the operations
so
> that
> they make sense when spoken as English. The ability to quickly follow
> reference chains in the IDE is a core skill in Smalltalk development,
so
> programmers should be well used to doing this and can easily use that
to
> map
> from control documentation to your higher level abstractions. Lastly
> you'll
> find (no doubt have found ) that there are places in any abstraction
where
> you want to deviate from the underlying control significantly, so to
avoid
> the "analysis paralysis" of attempting to keep a mapping between the
> control
> documentation and your abstraction, I would just let go of the
> relationship
> entirely and not worry about it :-)
>
> Regards
>
> Blair