Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #7727

Re: Function naming scheme

From Kaz Kylheku <686-678-9105@kylheku.com>
Newsgroups comp.programming
Subject Re: Function naming scheme
Date 2017-04-19 20:18 +0000
Organization Aioe.org NNTP Server
Message-ID <20170419130940.579@kylheku.com> (permalink)
References <od8ban$180m$1@gioia.aioe.org> <20170419121533.114@kylheku.com> <od8eas$1dvd$1@gioia.aioe.org>

Show all headers | View raw


On 2017-04-19, Victor Porton <porton@narod.ru> wrote:
> Kaz Kylheku wrote:
>
>> On 2017-04-19, Victor Porton <porton@narod.ru> wrote:
>>> I have two sets of similar (for pairings of functions from the different
>>> sets) functions: one for single orders and one for basket orders.
>> 
>> How about: an order contains a list of items. When that list is
>> length 1, we call it a single order; when it's two or more, we call it a
>> basket order. Then we don't need a separate type, with repeated
>> boiler-plate code that is almost the same except for handling a list
>> versus one item.
>
> Sorry, we have a set relational DB structure where single orders and basket 
> orders are represented differently. I don't have the power to change the DB 
> scheme.

Not buying it. Your abstraction in the code is independent of the DB
scheme.

If orders arrived over SMTP, would you require them to have a To, From,
Subject and MessageID?

> So them are two different cases and need to be processed somehow differently 
> (despite having much in common).

Like we can have length(list) and length(vector): processed differently,
same name.

Even if it turns out that you actually need a different data type for
single orders versus basket orders, they could have the same named
methods for the common thing.

Moreover, if the single order type actually uses the same data structure
to represent the list of orders as a basket order (e.g. a list of one
item), then they can probably share a lot of code in the base class.

Just dealing with the DB schema and whatnot can be specialized
to the specific type.

> We use Perl, we consider to rewrite all our software in PHP.

If the relevance of this remark is to confirm that your development
shop is daft, I assure you that it is redundant.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Function naming scheme Victor Porton <porton@narod.ru> - 2017-04-19 21:46 +0300
  Re: Function naming scheme Kaz Kylheku <686-678-9105@kylheku.com> - 2017-04-19 19:25 +0000
    Re: Function naming scheme Victor Porton <porton@narod.ru> - 2017-04-19 22:37 +0300
      Re: Function naming scheme Kaz Kylheku <686-678-9105@kylheku.com> - 2017-04-19 20:18 +0000
        Re: Function naming scheme Victor Porton <porton@narod.ru> - 2017-04-19 23:43 +0300
  Re: Function naming scheme Victor Porton <porton@narod.ru> - 2017-04-19 22:54 +0300

csiph-web