Classes and Fields

For users of dfns, both novice and expert

Classes and Fields

Postby petermsiegel on Tue Apr 16, 2024 10:22 pm

I know classes are out of favour these days, but hey, I have a use for them on occasion.
The issue: It looks like a field variable in a class behaves differently wrt hashing than a simple variable (not declared via :field).

Assume I have a private variable and a simple variable, each of which has been tagged as a hash (via ibeam 1500). If I use ,← to concat 1 or more values (here, char vectors), the hash status of the private variable is reset to 0, while the hash status of the simple variable remains 1 or 2 as expected.
Why is the behavior different?

Here's the class:
Code: Select all
:class test
    ⎕IO←0
   
    :Field Private  Peter←       ⍕¨⍳10
    :Field Private  Paul←        ⍕¨⍳10
    Mary←  ⍕¨⍳10

    ∇ make
  :Implements constructor
  :Access Public
    hash
  ∇

  ∇ check
  :Access Public
     'Peter',1( 1500⌶) Peter
      'Paul ',1( 1500⌶) Paul
      'Mary ',1( 1500⌶) Mary
  ∇

  ∇ access
  :Access Public
     _← Peter Paul Mary⍳¨⊂1 3 ¯5
     check
  ∇
  ∇ augment n
   :Access Public
     Peter,← ⍕¨10+⍳n
     Paul,← ⍕¨10+⍳n
     Mary,← ⍕¨10+⍳n
     access
   ∇
   ∇ hash
   :Access Public
      Peter← 1500⌶Peter
      Mary← 1500⌶Mary
     'Peter and Mary (re)hashed. Paul not hashed.'
     check
   ∇
:endclass
and here's some code:
Code: Select all
      a←⎕NEW test           
Peter and Mary (re)hashed. Paul not hashed (feel free to ignore).
Peter 1            ⍝ hashing turned on
Paul  0            ⍝ for reference only: no hashing turned on
Mary  1            ⍝ hashing turned on
      a.access     ⍝ search each object
Peter 2            ⍝ 2 as expected
Paul  0
Mary  2            ⍝ 2 as expected
      a.augment 1  ⍝ Append a char vector to each object via ,←
Peter 0
Paul  0
Mary  2
      a.access
Peter 0            ⍝ Expected to be 1 (woe is me)
Paul  0   
Mary  2            ⍝ Expected to be 2 (yay)
petermsiegel
 
Posts: 153
Joined: Thu Nov 11, 2010 11:04 pm

Re: Classes and Fields

Postby Vince|Dyalog on Wed Apr 17, 2024 3:49 pm

Hi Peter,

Hmm, why do you think that classes are out of favour?

Thanks for the reproducible example. I can reproduce the behaviour that you mention and will ask the developers about it.

Regards,

Vince
Vince|Dyalog
 
Posts: 419
Joined: Wed Oct 01, 2008 9:39 am

Re: Classes and Fields

Postby petermsiegel on Wed Apr 17, 2024 8:30 pm

Thanks so much.

Another one: if you declare but don’t initialize a field, its name class is non-zero, but it correctly has no value. You can’t use ⎕NC to check— you need to reference it and capture the VALUE ERROR or set your own flag. Easy workaround, but I could t find doc on the behaviour.

Here's a code snippet:
Code: Select all
     ↑⎕SRC metal
:class metal                 
   :Field gold               
                             
   ∇new                       
    :Implements constructor   
    :Access Public           
    ⎕←'⎕NC ¨gold¨= ',⎕NC'gold'
   ∇                         
                             
   ∇get                       
    :Access Public           
    :Trap 6                   
       ⎕←gold                 
    :Else                     
      ⎕←'gold has no value'   
    :EndTrap                 
    ∇                         
:endclass                     
      a←⎕NEW metal
⎕NC ¨gold¨=  2
      a.get
gold has no value


Re why do I think…
ANSWER: Classes are well used, but new features/innovation, time in general or focused tutorials or forums, frequency with which they are featured or highlighted, and other measures of design/development activity and buzz are way down across major programming languages including IMHO Dyalog. Not to mention the negativity of some “experts”. I like them for their strengths, as does ChatGPT!

Thanks again.
petermsiegel
 
Posts: 153
Joined: Thu Nov 11, 2010 11:04 pm

Re: Classes and Fields

Postby Vince|Dyalog on Tue Apr 23, 2024 9:55 am

Hi Peter,

I have logged your first issue as 21319: Hashed array in a class field loses its hash table if you extend it.

Could you say why you don't want to give the field an initial value in the first place please?

Here is a class metal2 in which I use a trigger functions as well as a horrible hack with ⎕size as two more alternatives of determining if the field has a value.

Code: Select all
:class metal2
    :Field gold
    :field goldset←0
    ∇ new
      :Implements constructor
      :Access Public
      ⎕←'⎕NC ¨gold¨= ',⎕NC'gold'
    ∇

    ∇ get
      :Access Public
     
    ∇
    ∇ goldtrigfn arg
      :Implements Trigger gold
      goldset←1
     
    ∇

    ∇ set
      :Access Public
      gold←42
    ∇

    ∇ r←check
      :Access public
      r←1
      :If 144=⎕SIZE'gold'
          ⎕←'gold has no value'
          r←0
      :End
      :If goldset
          ⎕←'gold has a value'
      :Else
          ⎕←'gold has no value'
          r←0
      :End
     
    ∇
:endclass


Regards,

Vince
Vince|Dyalog
 
Posts: 419
Joined: Wed Oct 01, 2008 9:39 am

Re: Classes and Fields

Postby petermsiegel on Tue Apr 23, 2024 3:46 pm

Thanks so much for your examples.

To answer your question: I really have 3 states-- defined and available as a default, defined but the value is temporarily not available (i.e. require objects to be defined for a spell), and never given a value at all by the "user."

I certainly can easily avoid the problem by having a state variable with 3 settings [SET, HIDDEN VALUE, NO VALUE], rather than checking the nameclass. I've essentially done that in reality-- now that I know. (Actually, I wrote the code many years ago and then "corrected" it back to using nameclass).

I'd just suggest this be part of the documentation, if it isn't, since it's semantically unintuitive to have an object with a (Dyalog-set) nameclass, without having any actual value.

But again, I can resolve this now that I know it's the expected semantics.

Thanks again...
petermsiegel
 
Posts: 153
Joined: Thu Nov 11, 2010 11:04 pm


Return to Functional Programming

Who is online

Users browsing this forum: Google [Bot] and 1 guest