[postgis-devel] Function Removal

[Bruce Rindahl]

The idea would be 'do no harm' (I know...) .  So the default values in the
case of ST_Translate would be 0 for deltax, deltay, deltaz so your example
would be ST_Translate(geom) would return the geom.  ST_Scale  would have
default values of 1.  You are right it would be a massive undertaking.
Would anyone care?  Or would they just get confused?

On Thu, Dec 17, 2020 at 2:47 PM Regina Obe <lr at pcorp.us> wrote:

> That example wouldn’t work even if we put in named args for those J
>
>
>
> Because we would then need to make x, y, z optional in ST_Translate, so
> that would require dropping those signatures and readding them.
>
> Let put aside the breakage in existing workflow for a minute
>
>
>
> But we would have to allow ST_Translate(geom)  - and what shoud that mean?
>
>
>
> and gosh that’s like 4 extra characters you have to type to save typing 1
> extra character J.  I know it’s clearer but
>
>
>
> what if we went by the docs
>
>
>
> ST_Traslate(geom, deltax => 10, deltay => 0)
>
>
>
> Are you going to remember is it  “x” or “deltax” J
>
>
>
> Is such clarity really worth the nuisance of having to reference the
> manual all the time for the name of the argument?
>
>
>
> I know I sound like an old nay-sayer stuck in the dark ages clinging on to
> the simplicity of the past.
>
>
>
> *From:* postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] *On
> Behalf Of *Bruce Rindahl
> *Sent:* Thursday, December 17, 2020 5:27 PM
> *To:* PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> *Subject:* Re: [postgis-devel] Function Removal
>
>
>
> I agree with all that but it could have advantages:
> ST_Translate(geom,x=>10) for a shift to the right,
> ST_Translate(geom,y=>10) for a shift up, ST_Scale(z=>10) for vertical
> distortion.
>
>   The functions , comments, and documents would all have to be updated and
> in sync with 'accepted' names.
>
>
>
> On Thu, Dec 17, 2020 at 2:19 PM Regina Obe <lr at pcorp.us> wrote:
>
> > Since they've come in we've really under-used named parameters. Some of
> > that because of legacy, some of it because of mental inertia. But for
> these
> > kinds of things they seem pretty ideal to me. Mean what you say, say what
> > you mean, have what your parameters mean be clear instead of opaque. A
> > good habit, all in all.
> >
> > P
> >
> In the beginning I thought named args were great, but I've come to think of
> them as being a little evil.
> Don't get me wrong -- they are indispensable in raster and pgRouting, cause
> there is a butt load of arguments and it's hard to undo or even
> questionable
> if we should.
>
> But for cases where we have few args, I find the evilness much worse than
> the disease they are there to cure.
>
> Mostly because of our indecision with coming up with good names and then
> changing our mind
> and then the fact our names in the docs don't even always match the named
> args ones we have .
>
> Remember Paul when your OCD kicked in and you decided to rename an arg?
>
> Oops we can't change the name of the arg without dropping the function oops
> we can't rename it because what if someone is using the name.
>
> So I don't care what the OGC says
>
> ST_Point(x,y, srid)
>
> With last arg always meaning srid seems clearest to me.
>
> No overloading with z,m etc.
>
> Have separate named functions for that.
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20201217/ffe928bb/attachment.html>