You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Milinda Pathirage <mp...@umail.iu.edu> on 2015/10/14 16:38:20 UTC
Why some methods in RexToLixTranslater are package-private?
Is there any technical reasons behind the $subject for 'translate' methods
in RexToLixTranslater?
Thanks
Milinda
--
Milinda Pathirage
PhD Student | Research Assistant
School of Informatics and Computing | Data to Insight Center
Indiana University
twitter: milindalakmal
skype: milinda.pathirage
blog: http://milinda.pathirage.org
Re: Why some methods in RexToLixTranslater are package-private?
Posted by Vladimir Sitnikov <si...@gmail.com>.
Last time I was "reusing some `translate` methods" it was somewhat
sufficient. I might happen I was lucky to use package-privates.
Can you tell more details (e.g. PR) on what you need?
Vladimir
Re: Why some methods in RexToLixTranslater are package-private?
Posted by Milinda Pathirage <mp...@umail.iu.edu>.
Hi Vladimir,
I want to use RexToLixTranslater to generate code for streaming window
aggregator. I'm trying to re-use existing code as much as possible. So I
want the methods to be public.
Thanks
Milinda
On Wed, Oct 14, 2015 at 1:27 PM, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> > Is there any technical reasons behind the $subject for 'translate'
> methods
> > in RexToLixTranslater?
>
> What is your question exactly?
> Do you want the methods to be private or public?
>
> I think the main reason for not-public is for encapsulation reasons:
> to reduce diversity of usage kinds, thus to reduce diversity of bug
> kinds.
> I would not say I like each bit of RexToLixTranslater, however it is
> nice to keep interface simple.
>
> Vladimir
>
--
Milinda Pathirage
PhD Student | Research Assistant
School of Informatics and Computing | Data to Insight Center
Indiana University
twitter: milindalakmal
skype: milinda.pathirage
blog: http://milinda.pathirage.org
Re: Why some methods in RexToLixTranslater are package-private?
Posted by Josh Elser <jo...@gmail.com>.
Thus is the pain of making the user's life easy and why actually
following semver's rules is (often elsewhere, in my opinion) passed over :)
Julian Hyde wrote:
> It may not manifest on the mailing list, but it does cause pain to
> Calcite developers. Every time we change or remove a public method we
> have to leave the old method marked deprecated until the next major
> release.
>
> On Wed, Oct 14, 2015 at 11:56 AM, Vladimir Sitnikov
> <si...@gmail.com> wrote:
>> I think we had a discussion on "public method" vs "published
>> interface" once (somewhere near 1.0 release).
>> For instance, adding an explicit annotation like @CalcitePublicAPI (or
>> .internal package) so consumers could distinguish "Calcite's internal
>> utility class" from "true public API (as in semver)".
>>
>> That however did not get much attention. It turned out we somehow
>> managed to live without it.
>> I do not find lots of questions on the list on the subject, thus
>> current approach seems to be good enough.
>>
>> I wonder if that would be a good starter / newbie jira issue.
>>
>> Vladimir
Re: Why some methods in RexToLixTranslater are package-private?
Posted by Julian Hyde <jh...@apache.org>.
It may not manifest on the mailing list, but it does cause pain to
Calcite developers. Every time we change or remove a public method we
have to leave the old method marked deprecated until the next major
release.
On Wed, Oct 14, 2015 at 11:56 AM, Vladimir Sitnikov
<si...@gmail.com> wrote:
> I think we had a discussion on "public method" vs "published
> interface" once (somewhere near 1.0 release).
> For instance, adding an explicit annotation like @CalcitePublicAPI (or
> .internal package) so consumers could distinguish "Calcite's internal
> utility class" from "true public API (as in semver)".
>
> That however did not get much attention. It turned out we somehow
> managed to live without it.
> I do not find lots of questions on the list on the subject, thus
> current approach seems to be good enough.
>
> I wonder if that would be a good starter / newbie jira issue.
>
> Vladimir
Re: Why some methods in RexToLixTranslater are package-private?
Posted by Vladimir Sitnikov <si...@gmail.com>.
I think we had a discussion on "public method" vs "published
interface" once (somewhere near 1.0 release).
For instance, adding an explicit annotation like @CalcitePublicAPI (or
.internal package) so consumers could distinguish "Calcite's internal
utility class" from "true public API (as in semver)".
That however did not get much attention. It turned out we somehow
managed to live without it.
I do not find lots of questions on the list on the subject, thus
current approach seems to be good enough.
I wonder if that would be a good starter / newbie jira issue.
Vladimir
Re: Why some methods in RexToLixTranslater are package-private?
Posted by Julian Hyde <jh...@apache.org>.
Vladimir is right. If we make a method public people assume it is a
public API and start using it, then we are accused of breaking
semantic versioning when we change something. This principle is even
more important in code like RexToLixTranslator which is a bit messy
and which we hope to clean up - or at least evolve - at some point.
That said, if you want something to become a public API, go ahead and
make a case for it and we will listen.
Julian
On Wed, Oct 14, 2015 at 10:27 AM, Vladimir Sitnikov
<si...@gmail.com> wrote:
>> Is there any technical reasons behind the $subject for 'translate' methods
>> in RexToLixTranslater?
>
> What is your question exactly?
> Do you want the methods to be private or public?
>
> I think the main reason for not-public is for encapsulation reasons:
> to reduce diversity of usage kinds, thus to reduce diversity of bug
> kinds.
> I would not say I like each bit of RexToLixTranslater, however it is
> nice to keep interface simple.
>
> Vladimir
Re: Why some methods in RexToLixTranslater are package-private?
Posted by Vladimir Sitnikov <si...@gmail.com>.
> Is there any technical reasons behind the $subject for 'translate' methods
> in RexToLixTranslater?
What is your question exactly?
Do you want the methods to be private or public?
I think the main reason for not-public is for encapsulation reasons:
to reduce diversity of usage kinds, thus to reduce diversity of bug
kinds.
I would not say I like each bit of RexToLixTranslater, however it is
nice to keep interface simple.
Vladimir