|
»
Re: Geom/Geog Hack Plan
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
Re: Geom/Geog Hack Plan
by Nicklas Avén
::
Rate this Message:
Just a question for my understanding.
What's the argument against a special prefix in function-name for those functions.
If the argument is that we then can implement the "real" function in a micro-release, I don't think it is a good argument.
Exchanging the hacked version with the real will cause a changed behavior of the function and is probably not what users expect from a micro-release, from the policy not to change functionality in micro-releases.
/Nicklas
_______________________________________________ postgis-devel mailing list postgis-devel@... http://postgis.refractions.net/mailman/listinfo/postgis-devel |
|
|
Re: Geom/Geog Hack Plan
by Paragon Corporation-2
::
Rate this Message:
Nicklas,
Well actually we wouldn't change it in a micro release.
Yes I agree changing output in the micro release is probably a no
no.
We'd change it in a minor or major release (proably major
in this case in 2.0). As far as naming goes yes that is the basic
argument. That if we replace the function with a real one. The real
one will do "more the right thing" than the old. So in essense it would be
treated like a bug fix rather than a mere change of
behavior.
That does bring up the question of:
Is the right answer the one you are expecting or the one
you expect.
(are expecting meaning the one you are used to vs. you expect
(without any prior expectations of behavior))
For example in SQL 1/2 => 0 (both PostgreSQL and SQL Server
and a lot of relational databases behave this way by the
way)
But if I change the behavior to suddenly return
0.5 (like MySQL
does)
Do people consider it wrong because it is no longer the
expected answer of 0, but from a mathematical point of view, it is the one you
expect.
Thanks,
Regina From: postgis-devel-bounces@... [mailto:postgis-devel-bounces@...] On Behalf Of nicklas.aven@... Sent: Tuesday, November 03, 2009 6:07 AM To: PostGIS Development Discussion Subject: Re: [postgis-devel] Geom/Geog Hack Plan Just a question for my understanding.
What's the argument against a special prefix in function-name for those
functions.
If the argument is that we then can implement the "real" function in a
micro-release, I don't think it is a good argument.
Exchanging the hacked version with the real will cause a changed behavior
of the function and is probably not what users expect from a micro-release, from
the policy not to change functionality in micro-releases.
/Nicklas
> >I'm in agreement with Mark too. I suppose one or 2 of these functions is >not going to pollute our 1.5 that much. > >So how about this as a plan: > >Paul picks 1 or 2 more of these kind of functions. Note we already have >buffer -- which is now documented. Though not sure if the documentation is >clear enough - >http://www.postgis.org/documentation/manual-svn/ST_Buffer.html (and I think >we need to revise our documentation template yet again -- though I'll put >that in a separate note). > >The rest of the functions get put in a wiki page and prominently linked from >the documentation > > > in geography index >http://www.postgis.org/documentation/manual-svn/ch08.html#PostGIS_GeographyF >unctions > >as well as geography description page > > for easy access >http://www.postgis.org/documentation/manual-svn/ch04.html#PostGIS_Geography > >Is everyone okay with that plan? > >Thanks, >Regina > > >_______________________________________________ >postgis-devel mailing list >postgis-devel@... >http://postgis.refractions.net/mailman/listinfo/postgis-devel > > postgis-devel mailing list postgis-devel@... http://postgis.refractions.net/mailman/listinfo/postgis-devel |
|
|
Re: Geom/Geog Hack Plan
by Havard Tveite
::
Rate this Message:
nicklas.aven@... wrote:
> Just a question for my understanding. > What's the argument against a special prefix in function-name for those > functions. One possible argument: One should not introduce a separate name for a function that is just a hack for the proper function. One could consider introducing a separate name for such a function if it would be interesting to use the function its own right once the proper function is fully implemented and in place. Less functions to document and maintain. Håvard > If the argument is that we then can implement the "real" function in a > micro-release, I don't think it is a good argument. > Exchanging the hacked version with the real will cause a changed > behavior of the function and is probably not what users expect from a > micro-release, from the policy not to change functionality in > micro-releases. > > /Nicklas > > 2009-11-03 Paragon Corporation wrote: > > Paul and Kevin, > > > >I'm in agreement with Mark too. I suppose one or 2 of these functions is > >not going to pollute our 1.5 that much. > > > >So how about this as a plan: > > > >Paul picks 1 or 2 more of these kind of functions. Note we already have > >buffer -- which is now documented. Though not sure if the documentation is > >clear enough - > >http://www.postgis.org/documentation/manual-svn/ST_Buffer.html (and I > think > >we need to revise our documentation template yet again -- though I'll put > >that in a separate note). > > > >The rest of the functions get put in a wiki page and prominently > linked from > >the documentation > > > > > > in geography index > >http://www.postgis.org/documentation/manual-svn/ch08.html#PostGIS_GeographyF > >unctions > > > >as well as geography description page > > > > for easy access > >http://www.postgis.org/documentation/manual-svn/ch04.html#PostGIS_Geography > > > >Is everyone okay with that plan? > > > >Thanks, > >Regina postgis-devel mailing list postgis-devel@... http://postgis.refractions.net/mailman/listinfo/postgis-devel |
|
|
Re: Geom/Geog Hack Plan
by Paragon Corporation-2
::
Rate this Message:
Yap that's my thinking. For this scenario, I can't really think of anyone
preferring the less accurate answer when/if the more accurate is available. So code would be easier to migrate if people didn't need to change function names to use the new and improved. Plus I'm lazy. its easier to add a proto to an existing function in the docs than a whole new function :) Thanks, Regina -----Original Message----- From: postgis-devel-bounces@... [mailto:postgis-devel-bounces@...] On Behalf Of Havard Tveite Sent: Tuesday, November 03, 2009 8:29 AM To: PostGIS Development Discussion Subject: Re: [postgis-devel] Geom/Geog Hack Plan nicklas.aven@... wrote: > Just a question for my understanding. > What's the argument against a special prefix in function-name for > those functions. One possible argument: One should not introduce a separate name for a function that is just a hack for the proper function. One could consider introducing a separate name for such a function if it would be interesting to use the function its own right once the proper function is fully implemented and in place. Less functions to document and maintain. Håvard > If the argument is that we then can implement the "real" function in a > micro-release, I don't think it is a good argument. > Exchanging the hacked version with the real will cause a changed > behavior of the function and is probably not what users expect from a > micro-release, from the policy not to change functionality in > micro-releases. > > /Nicklas > > 2009-11-03 Paragon Corporation wrote: > > Paul and Kevin, > > > >I'm in agreement with Mark too. I suppose one or 2 of these > functions is >not going to pollute our 1.5 that much. > > > >So how about this as a plan: > > > >Paul picks 1 or 2 more of these kind of functions. Note we already > have >buffer -- which is now documented. Though not sure if the > documentation is >clear enough - > >http://www.postgis.org/documentation/manual-svn/ST_Buffer.html (and I > think >we need to revise our documentation template yet again -- > though I'll put >that in a separate note). > > > >The rest of the functions get put in a wiki page and prominently > linked from >the documentation > > > in geography index > >http://www.postgis.org/documentation/manual-svn/ch08.html#PostGIS_Geo > graphyF > >unctions > > > >as well as geography description page > > for easy access > >http://www.postgis.org/documentation/manual-svn/ch04.html#PostGIS_Geo > graphy > > > >Is everyone okay with that plan? > > > >Thanks, > >Regina postgis-devel mailing list postgis-devel@... http://postgis.refractions.net/mailman/listinfo/postgis-devel _______________________________________________ postgis-devel mailing list postgis-devel@... http://postgis.refractions.net/mailman/listinfo/postgis-devel |
| Free embeddable forum powered by Nabble | Forum Help |
