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

Groups > comp.programming > #7722 > unrolled thread

Function naming scheme

Back to article view | Back to comp.programming

Contents

  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

#7722 — Function naming scheme

I have two sets of similar (for pairings of functions from the different 
sets) functions: one for single orders and one for basket orders.

Should I name the functions like ProcessOrder/ProcessOrderBasket or 
ProcessOrderSingle/ProcessOrderBasket?

-- 
Victor Porton - http://portonvictor.org

[toc] | [next] | [standalone]

#7723

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.

> Should I name the functions like ProcessOrder/ProcessOrderBasket or 
> ProcessOrderSingle/ProcessOrderBasket?

I'd use a programming language in which I can have polymorphic function
or method called "process", which can work on objects of various types.

   order.process(); // process the order: any kind of order

   cheese.process(); // process the cheese; totally different

-- 
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List:  http://www.kylheku.com/diy
ADA MP-1 Mailing List:   http://www.kylheku.com/mp1

[toc] | [prev] | [next] | [standalone]

#7724

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.

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

>> Should I name the functions like ProcessOrder/ProcessOrderBasket or
>> ProcessOrderSingle/ProcessOrderBasket?
> 
> I'd use a programming language in which I can have polymorphic function
> or method called "process", which can work on objects of various types.
> 
>    order.process(); // process the order: any kind of order
> 
>    cheese.process(); // process the cheese; totally different

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

These are set facts, I cannot freely choose a language of preference.

We this `cheese` can be don in Perl with object oriented programming, but 
this would increase complexity rather that decrease.

-- 
Victor Porton - http://portonvictor.org

[toc] | [prev] | [next] | [standalone]

#7727

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.

[toc] | [prev] | [next] | [standalone]

#7729

Kaz Kylheku wrote:

> 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.

See my another message in this thread.

I have finally realized that I can process both cases in one control flow 
(not two "parallel" sets of functions).

-- 
Victor Porton - http://portonvictor.org

[toc] | [prev] | [next] | [standalone]

#7725

Victor Porton 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.
> 
> Should I name the functions like ProcessOrder/ProcessOrderBasket or
> ProcessOrderSingle/ProcessOrderBasket?

Now I've understood that I can do both using only "basket" set of functions. 
I can just pass NULL as the basket ID and a single order info to a function.
A little if-else (checking if the basket is NULL) for differentiating 
singular and basket orders should do the job.

Feeling stupid for not noticing this before.

-- 
Victor Porton - http://portonvictor.org

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web