define methods for properties and associations getter/setter

[senid231]

Description

• undo performance optimization introduced in Dynamic attribute optimizations #281
• add performance optimization when defining properties and relationships
• introduce association setter

It's a bad practice to dynamically create methods when accessing method missing, so I changed a behavior of of static define attributes.

Generally I add accessors for each attribute that defined with property class method and relactionships that defined with has_one, has_many, and belongs_to class methods

performance may be decreased comparing to previous version unless you define properties for all accessed attributes

[jsmestad]

I like the change. There does seem to be quite a bit of style change embedded in this PR though. I'd suggest splitting out the feature change from the code style changes.

To explain that a little more:

Given the lack of documentation on this project, that means folks often rely on reading the source code to find their answer. As a result the code-style being uniform has a greater impact on library comprehension. - If you want to suggest the style changes, we probably would want to do it across the library.

[gaorlov]

Thanks for your work! These are solid changes.
My comments are similar to @jsmestad:
Can we move the association logic out of Resource into a concern-like module? Associations for example?

It may be easier to read & test if that code is contained in a single module.

The way i've done it before it to have an Associable concern that defines has_one, etc functions and handles all that business. Something like

module JsonApiClient
  module Associatable
    extend ActiveSupport::Concern

    included do

      class_attribute :__associations
      self.__associations = {}

      attr_accessor :__cached_associations

      class << self

        def belongs_to( name, opts = {} )
          process Associations::BelongsTo.new( self, name, opts )
        end

        def has_one( name, opts = {} )
          process Associations::HasOne.new( self, name, opts )
        end

        def has_many( name, opts = {} )
          process Associations::HasMany.new( self, name, opts )
        end
        
        protected

        def process( association )
          associate association
          methodize association
        end

        def associate( association )
          self.__associations = __associations.merge association.name => association
        end

        def methodize( association )
          define_method association.name do
            self.__cached_associations ||= {}

            unless self.__cached_associations.has_key? association.name
              self.send( "#{association.name}=", association.fetch( self ) )
            end
            self.__cached_associations[association.name]
          end

          define_method "#{association.name}=" do | value |
            self.__cached_associations ||= {}
            self.__cached_associations[association.name] = value
          end
        end
      end
    end
  end
end

Does that make sense?

Functionally, again, this is solid.

[senid231]

@jsmestad thanks for your review. I agree with you. I'll remove style changes and introduce styling refactor MR later.
I want to use rubocop here cause I've found it very useful in my other projects.

[senid231]

@gaorlov thanks for your review. I agree that code will be more readable if we move associations logic into separate concern.

[gaorlov]

How can I help?

[senid231]

@jsmestad @gaorlov I've updated the PR
please take a look

[gaorlov]

This looks really solid. My only comment is whether we need some code in method_missing. Nicely done.

[gaorlov]

since creating an association generates the accessor methods, will a relationship ever get into method_missing?
If not, do we need this code?

[senid231]

good catch)

[senid231]

@gaorlov, I've changed it. Take a look

[gaorlov]

Looks great! Nicely done.

[gaorlov]

oh, man.
That's so much nicer to read! Strong work!

[gaorlov]

Looks solid