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

Groups > comp.programming > #9289 > unrolled thread

.paid field vs .payment field

Back to article view | Back to comp.programming

Contents

  .paid field vs .payment field Victor Porton <porton@narod.ru> - 2018-09-20 22:33 +0300
    Re: .paid field vs .payment field Victor Porton <porton@narod.ru> - 2018-09-22 16:40 +0300
    Re: .paid field vs .payment field Julio Di Egidio <julio@diegidio.name> - 2018-09-22 07:11 -0700
      Re: .paid field vs .payment field Victor Porton <porton@narod.ru> - 2018-09-22 17:17 +0300
        Re: .paid field vs .payment field Julio Di Egidio <julio@diegidio.name> - 2018-09-25 01:21 -0700
          Re: .paid field vs .payment field Victor Porton <porton@narod.ru> - 2018-09-25 18:59 +0300
            Re: .paid field vs .payment field Julio Di Egidio <julio@diegidio.name> - 2018-09-25 09:43 -0700
    Re: .paid field vs .payment field Julio Di Egidio <julio@diegidio.name> - 2018-09-22 08:53 -0700

#9289 — .paid field vs .payment field

Let us narrow the task:

I am writing a class SimpleItem representing a non-recurrent (one-time) 
purchase. That is the payment is not recurring, it is normally paid at most 
once (however, such things as refunds may happen).

The class SimpleItem has field .payment which is an instance of 
SimplePayment, a class representing a result of user interaction which led 
to a payment.

Now, my question: Should I also have boolean field SimpleItem.paid? It seems 
that I can determine whether there was a payment by checking that .payment 
is non-NULL. So it seems that .paid field is not necessary. But maybe there 
are arguments for the contrary?

The API needs to be quality and usable.

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

[toc] | [next] | [standalone]

#9292

Victor Porton wrote:

> Let us narrow the task:
> 
> I am writing a class SimpleItem representing a non-recurrent (one-time)
> purchase. That is the payment is not recurring, it is normally paid at
> most once (however, such things as refunds may happen).
> 
> The class SimpleItem has field .payment which is an instance of
> SimplePayment, a class representing a result of user interaction which led
> to a payment.
> 
> Now, my question: Should I also have boolean field SimpleItem.paid? It
> seems that I can determine whether there was a payment by checking that
> .payment is non-NULL. So it seems that .paid field is not necessary. But
> maybe there are arguments for the contrary?
> 
> The API needs to be quality and usable.

Related question: Should .payment be reset to NULL on payment refund event?

(If no, then we need both .payment and .paid because in this case .paid 
should be reset to False but .payment not reset to NULL.)

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

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

#9293

On Thursday, 20 September 2018 21:33:18 UTC+2, Victor Porton  wrote:

> I am writing a class SimpleItem representing a non-recurrent (one-time) 
> purchase.

Call it SimplePurchase then, and have it "contain" a SimpleItem as well as
a SimplePayment (there's hardly any reason not to abstract the two apart),
as well as, maybe, a SimpleRefund... i.e. depending on your business-level,
aka explicit, *requirements*.

HTH,

Julio

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

#9297

Julio Di Egidio wrote:

> On Thursday, 20 September 2018 21:33:18 UTC+2, Victor Porton  wrote:
> 
>> I am writing a class SimpleItem representing a non-recurrent (one-time)
>> purchase.
> 
> Call it SimplePurchase then, and have it "contain" a SimpleItem as well as
> a SimplePayment (there's hardly any reason not to abstract the two apart),
> as well as, maybe, a SimpleRefund... i.e. depending on your
> business-level, aka explicit, *requirements*.

No, SimpleItem already has foreign key to SimplePayment. There is no need 
for SimplePurchase to link to SimplePayment too.

> HTH,
> 
> Julio

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

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

#9299

On Monday, 24 September 2018 23:02:34 UTC+2, Victor Porton  wrote:
> Julio Di Egidio wrote:
> > On Thursday, 20 September 2018 21:33:18 UTC+2, Victor Porton  wrote:
> > 
> >> I am writing a class SimpleItem representing a non-recurrent (one-time)
> >> purchase.
> > 
> > Call it SimplePurchase then, and have it "contain" a SimpleItem as well as
> > a SimplePayment (there's hardly any reason not to abstract the two apart),
> > as well as, maybe, a SimpleRefund... i.e. depending on your
> > business-level, aka explicit, *requirements*.
> 
> No, SimpleItem already has foreign key to SimplePayment.

That is still total nonsense: even if you collapse the notions of purchase and
item, it's the item (purchase) that may have a payment, not the other way round.

> There is no need for SimplePurchase to link to SimplePayment too.

Indeed, that would make even less sense.

And if that's beyond your understanding, get a job in agriculture.

*Plonk*

Julio

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

#9300

Julio Di Egidio wrote:

> On Monday, 24 September 2018 23:02:34 UTC+2, Victor Porton  wrote:
>> Julio Di Egidio wrote:
>> > On Thursday, 20 September 2018 21:33:18 UTC+2, Victor Porton  wrote:
>> > 
>> >> I am writing a class SimpleItem representing a non-recurrent
>> >> (one-time) purchase.
>> > 
>> > Call it SimplePurchase then, and have it "contain" a SimpleItem as well
>> > as a SimplePayment (there's hardly any reason not to abstract the two
>> > apart), as well as, maybe, a SimpleRefund... i.e. depending on your
>> > business-level, aka explicit, *requirements*.
>> 
>> No, SimpleItem already has foreign key to SimplePayment.
> 
> That is still total nonsense: even if you collapse the notions of purchase
> and item, it's the item (purchase) that may have a payment, not the other
> way round.

No, there are links in BOTH directions:

Several SimplePayment objects may link to one SimpleItem (many-to-one).

But SimpleItem may link to one (or zero) unique SimplePayment (name it X). 
The back link from this SimplePayment is to this SimpleItem, but that X is a 
"special" payment, the one payment which was the last successful payment of 
this item.

So, you misunderstood me because you didn't know what there are links in 
both directions.

>> There is no need for SimplePurchase to link to SimplePayment too.

See above.

> Indeed, that would make even less sense.
> 
> And if that's beyond your understanding, get a job in agriculture.

You can read my abstract Nobel-level (yes, I know no Nobel in math) math 
research at:
http://www.mathematics21.org/algebraic-general-topology.html

It is not agriculture.

> *Plonk*
> 
> Julio
-- 
Victor Porton - http://portonvictor.org

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

#9301

On Tuesday, 25 September 2018 17:59:14 UTC+2, Victor Porton  wrote:

> No, there are links in BOTH directions:

Where you completely miss what is what and the very distinction between a
conceptual model and an implementation model.  And that the conceptual part
rather *drives*, not the other way round: e.g. "links" implement _relations_,
and it's the relations that you should find and model to begin with.  Just to
mention the tip of an iceberg.

But I know you have a background in mathematics, that's why I rather expected
you to be able to at least parse precise statements and definitions, or know
what a _relation_ is, etc., even if you have no clue about implementation.

> You can read my abstract Nobel-level (yes, I know no Nobel in math) math
> research at: http://www.mathematics21.org/algebraic-general-topology.html

Sure, I have seen it in sci.math, crank!  Not that sci.math is anymore that
relevant, of course, but you are being utterly ridiculous...

And now you get a job in software, as many, and as many with some mathematical
background (and this includes 99% of the computer scientists), you think you
are a genius of software...  Well, sorry to break it on you, but software
*engineering* is *the most complex engineering that there is*, and yours is
just yet another instance of the Dunning-Kruger effect: to put it charitably.

Indeed, it's pretty normal to be totally confused when first approaching real
programming and real software (already the discipline of naming things is a
total nightmare to the beginner): and not just because of the *tons* of *crap*
that one usually finds online (Wikipedia on anything software *not* being any
exception), but more fundamentally, I'll say it again,  *software is the
most complex engineering that there is*.  So, I really do not have it with
your cluelessness, I have it with your unmitigated arrogance and the frauds
that necessarily come with it...

Bottom line, learn to use question marks, that might help.

Have a nice day,

Julio

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

#9294

On Thursday, 20 September 2018 21:33:18 UTC+2, Victor Porton  wrote:

> Now, my question: Should I also have boolean field SimpleItem.paid? It seems 
> that I can determine whether there was a payment by checking that .payment 
> is non-NULL. So it seems that .paid field is not necessary. But maybe there 
> are arguments for the contrary?

No "magic values"...  The canonical good solution for such cases is have an
(enumerable) purchase-state field.

HTH,

Julio

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web