Skip to content

Naming Conventions

Mitch VanDuyn edited this page Aug 9, 2018 · 3 revisions

Proposal 1:

# Component base class
HyperComponent 

# Store base class
HyperStore  

# The router
HyperRouter

# Operation base class
HyperOperation 

# subclass of HyperOperation
HyperServerOp 

# client side base class for models
HyperModel 
# note that HyperStack ActiveRecord adapter will use HyperModel under the hood

For each class there is a corresponding Mixin module: HyperComponent::Mixin, HyperStore::Mixin, etc.This is a bit odd as the mixin is internal to the class but it saves typing for the most common case.

Internal modules and classes not intended as public APIs will be named like this:

HyperStack::Component::SomeModule

THINK ON THIS

The above approach for naming the public classes and mixins was agreed last year, and its major intent was to be clear, avoid namespace collisions with application classes, while keeping names as short as possible. The earlier (now deprecated) approach was to use the same approach as Rails ActiveRecord. I.e. Hyperstack::Component::Base is the class.

Meanwhile Rails now takes this approach of having an ApplicationRecord class.

Well we could do this too:

class ApplicationComponent < Hyperstack::Component::Base
# handy place to add common application specific callbacks etc...
end

Anyway NOW IS THE TIME TO DECIDE... so add yer comments ASAP!

MUCH MORE MINOR THOUGHT

HyperOperation::ServerOp is a mouthful

we could just use a macro, which adds the ServerOp functionality:

class MySecretOp < Hyperloop::Operation
  allow_remote_access ... some parameters to control ...
end

I have to go back over notes discussed 2 years ago (!!!) with Barrie... any ideas on this welcome.

Clone this wiki locally