-
Notifications
You must be signed in to change notification settings - Fork 11
Naming Conventions
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.